Tuesday, October 04, 2005


When you're a developer - of any kind - you rely on the tools, equipment and materials that you need to do your job.

Some things don't need introductions to their use. Hammers, for example, generally are hammers, and you hit things with them. It's kind of expected that when you buy a hammer, you already know how to hit things (and this is more complicated than it sounds!). Still, if I bought Homer Simpson's automatic hammer, I'd expect a manual that went into detail about its use - even if it should be bloody obvious.

Why doesn't this happen with the bleeding edge - or even the dull edge - of software?

When Microsoft publishes a new technology, it goes the whole hog - examples, documentation, tutorials, extensive testing - before it ever goes Beta 1. This means that you and I can plough in straight away and start trying it out without having to know every nasty little detail. You might not like the technology, and you might not approve of their motives - but their execution is stellar.

Other people aren't quite so complete. Take log4cplus (no, please, take it away!), for example. There seems to be a dearth of logging libraries for C++, otherwise surely this would never be used, much less adopted by companies as their "logging standard". It has no documentation of significance. In order to figure out how to use it, you study code written with it, and you study its code, and you study (and discard) the meager API docs, and then you experiment trial-and-error style.

The purpose of this post is not to dig at log4cplus. Rather, I would dig at the entire community which finds it acceptable to do the minimum possible for a project, then mark it "Production".

It ain't done until it's complete, people. Complete doesn't mean bug-free, and as much as I'd like to see that happen, it just never does. Complete does mean that the package is done, though, and the package is more than software.

You have a customer, even if it's just you. You need to get the software onto their machine and help them, every step of the way, to do what they want to do with it. This means installation. This means documentation (and documentation is not just Doxygen or Javadoc). This means intuitive and consistent interfaces. This means coping with non-admins. This means testing. This means support.

Developer tools are not exempt from these requirements. In fact, developers are an even more demanding set - or should be. A developer has to meet all these requirements themselves, and if you haven't provided what you had a duty to do, you have failed your customer.

Even if you have no bugs.

If you can't deliver a package, think again about what you're doing.


Post a Comment

Links to this post:

Create a Link

<< Home