UTF-16 exists to allow Java and other languages with 16-bit chars the ability to represent the entire Unicode character set. It's not recommended for languages that support 8-bit characters, IIRC.

Not exactly. "The entire Unicode character set" is UCS-32. UTF-16 encodes the extended, extended characters as pairs.


Proper 32-bit Character support was subsequently bolted on to Java, and it's a bit ugly.

I was afraid that would be the answer. UTF-16 does what UTF-8 does, but less efficiently, but it's the standard in Windows so we're stuck with it.

Apparently UTF-16 is more efficient if you're mostly encoding CJK languages.

Windows does have to support such languages as Chinese and Japanese (in their various alphabets), etc. For those customers, I suppose it'd be kinda frustrating to work with UTF-8.

OTOH, it sucks when you write in English and everything you do is twice the size required to store the document.

But then, you can save your documents UTF-8 or ANSI or some other encoding.

I don't speak any of those languages. This sounds like some sort of conspiracy.

How dare the majority of people in the world speak a language that requires 16-bit representation!

I think the idea behind agile predates the use of that term.

Waterfall doesn't really work well. Planning the entire effort is, basically, impossible, with so many variables involved, and the surprises you learn along the way for any large project. In the end, the customer doesn't get what they wanted, even though they get the product to which they agreed.

I think any software engineer would get this. Work on chunks of a project at a time, and be prepared to change course in the middle of things when you learn that something isn't quite going to work accoding to expectations, or the customer realizes that what they thought would work for them won't.

Heh... 'accoding'...

Back when I worked on WinINSTALL, we did agile. We didn't know it by that name, and we didn't follow any sort of formal methods proposed to us, because no such name as 'agile' existed then, as far as I knew. I recall going to a class intending to teach people how to write software more quickly... I thought the close would focus on programming techniques, but it instead focused on project management. That got me interested in the subject, and I guess I've been keeping up with some of these trends since then, at least to some degree.

I don't know exactly when SCRUM and Agile and other such terms came about, but I know software engineers had already been doing that for a long time before formalizing the methods in a book and teaching them to incoming project managers who had never written a lick of code in their life.

DAD feels like more of the same, except formalizing these things for a corporation.
It seems to emphasize such things as discussions with the people who need to use the product, getting ongoing information as the product develops to ensure that the customer gets what they want rather than an agreed-upon specification that doesn't actually help them. It isn't quite clear to me how it helps a higher-level manager understand that the project isn't out of control (something that can be obvious to a lead, or to a manager closing examining the progress), since most of those guys want something like waterfall, which gives a false sense of security that a project is going according to plan when you can't really plan it that way in the first place.

I just learned that I am probably going to be called upon to be a Scrum Master.
For the first order of business, I will mandate that everyone maintain a video presence on all team meetings, and must be dressed as their favorite Minecraft character.

Your life will be sprinting for job to job. Fun.

Applying the Agile method to non-programming work is an experiment. We're going to see how it goes. Separating our architecture/engineering team from our customer-facing teams has been a huge success. Now we have to wrangle the way we take in and complete work.

The trick will be to learn how to divide projects into chunks of work that can be completed during each cycle. And if it doesn't work, we'll try something else. We're already a high output team but we're trying to make things a little less chaotic.

I find kanban is especially applicable to non-programming tasks. (It was, originally, part of the Toyota manufacturing process, so I guess that kind of makes sense that it would.)

2017-06-03 13:47 from IGnatius T Foobar @uncnsrd
Applying the Agile method to non-programming work is an experiment.

Sounds like someone needs to pad their resume.

The top decision maker who is making this effort happen is not a resume-padder.
He's looking for a way to better organize the workflow into and through a heavily loaded team.

Kanban does happen to be the process we're using.

I've used kaban. It's not bad.. The biggest goals for teams is to have a process. Follow the process and then tweak the process where it doesn't work.. Always evaluating.

And if it doesn't work, throw it out.

My previous employer had a bad habit of piling on more process steps every time something went wrong. This leads to a slow death by suffocation.

Here, we're very lean: no branching code, use feature-toggles or the branch-by-abstraction pattern to turn off anything that is not fully vetted. A company that's growing fast and adding partners fast, sometimes 4 in a week, to a shared-hosting platform, can not afford to push QA cycles out to 1 month each...


Delivery is everything.

Heh... 'delivery is everything'...

Sorta. Design failures that lead to increasingly delayed deliveries muddy those waters.

Delivery is everything.. Accurate delivery more suprising?

Old Adage.. But so true.

System Development is based on three things.

1) On Time
2) On Budget
3) On Target

Choose any two.