A few days ago I wrote about Google putting their weight behind HTML 5 and now it looks like Palm is pushing it too. The "mojo" developer's kit is based on HTML 5 and uses Javascript as the primary language. I still have some serious reservations about building serious apps in javascript. It just feels fagile. Bailing wire and chewing gum is not the feeling I want when building apps. The unholy alliance of javascript and HTML has made web apps a lot more interesting but it's still a very breakable platform.

Palm has taken an interesting approach though. They are providing a library of application components that are scripted by javascript. Palm has most likely built those core modules in c++, java or something more robust. Javascript is used, as it's name implies, as a scripting language.

I'll be keeping an eye out to see how successful this combination becomes.

Bob Martin has been getting people to sign a "Manifesto of Software Craftsmanship" which sounded interesting but turned out to be completely useless. I'm all for promoting professional standards and practices in the developer community but this thing is just a glorified email sign up list. The total text of the manifesto is two paragraphs and four bullet points which can be summarized:

We value well crafted software. (a self reference to the title, software craftsmanship)

We like it when you add value to a program. (Really, because people don't usually pay for programming otherwise)

We like communities of professionals

We like it when programmers help each other.

This is followed by a long list of people who signed the damn thing.  Did anyone read this thing? It's like signing a document that says "I'm a good professional because I like professionalism."

Instead of making a fancy background image so your manifesto looks like an old parchment how about taking the time to record some knowledge. How do you acomplish those items? Why do you want those things? How are you going to measure if you're meeting your goals? If anyone can sign what does it mean?

I've been adding some unit tests to a Base64 encoding library and discovered that the existing code did not properly handle some non-english characters. I traced the error to the code which converts a string into an array of bytes. I figured, "oh", boneheaded move. I was expecting that each character would be stored in a single byte and I just need to expect two bytes per character because I'm dealing with Unicode strings in .Net.

That got me a little farther but then I realized that the byte order was reversed from what I expected it to be. The letter A would convert to 0x41, 0x00 instead of what I expected which was 0x00, 0x41. Fix that and now some of the tests are passing and some are failing. 

Two hours later I realize that I had a link to this great article The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) by Joel Spolsky.If you're having any similar issues you should read this article first.

It turns out that UTF-8, which is what Microsoft uses for most string conversion in .Net dynamically chooses how many bytes to write per character based on what's needed. The normal ASCII characters like A are encoded in a single byte and the larger characters are encoded in 2 or more bytes.

I adjusted my test cases to account for the way UTF-8 really works instead of the way I thought all unicode strings were handled and green lights across the board for the unit tests. Hope this saves someone else the time that I wasted.

The Richmond Software Craftsman Group had our monthly meeting last night and we discussed developer productivity. Lines of Code (LOC) was suggested as the common measure of productivity. I think everyone quickly agreed that LOC produced was not really a good measure of effeciency. You'll quickly end up with bloated code because the measurement says that it is preferred.

Measuring team performance seems to be easier than individual productivity and I think this is what should be measured:

1) On Time
2) On Budget
3) Product Does what was expected (This would include a measure of defects for quality).
4) Client satisfaction with what was delivered.


- On Time: Did the team estimate the project well. Steve McConnell has a great book on software estimation and a lot of it boils down to "engineers are overly optimistic even when they think they're not."

- On Budget: Almost a directly correlation to time but if you use double to resources planned to hit a target your budget it blown. Budget should be a function of work estimates and timeline.

- Product does what was expected: Did you deliver everything that you said you would? Do the features do what they are expected to do. If features are buggy they do not do what was expected. I'm thinking this is kind of like acceptable failure rate in manufacturing. NASA will pay big bucks to have a very low bug rate but Joe's flower mart down the street might accept a higher bug rate in exchange for a much lower budget. Developers should set an expected defect rate that isn't zero because it's not realistic.

- Client satisfaction: This measures a couple of things. Did you accurately capture requirements from the customer? Did you communicate what you are going to build effectively so that client expectations are set correctly? Does the client understand the expected bug rate in the finished product and how it will affect timeline and price?


I think that inside a team it can be much more difficult to measure productivity because each team member influences the others. If a hole punch machine in the factory is misaligned the rubber gasket machine may produce defective parts. The gasket machine had garbage in so it gave garbage out. One programmer building a crucial module can delay other programmers making it very difficult to measure the individual productivity. Network effects can influence the team in positive and negative ways.