October 16, 2007

...Learn TDD with Codemanship

Business-Critical Means Quality-Critical

I often marvel at how it's almost always the same people who run around like headless chickens when a web site goes down or the network plays up, screaming their lungs inside-out about how much all this outage is costing, who also shrug their shoulders and say "no big deal" when they're confronted with the poor quality of the software they deliver.

While faults in most business systems - web sites included - may not cause loss of life or limb, they can certainly cost loss of money. Lots of money. Apart from the lost productivity or lost sales (or lost customer records) that business system defects can cause, there are also less tangible - but sometimes more harmful - effects like long-term damage to your brand and the lowering of staff morale.

Indeed, I despair at just how unreliable some buiness systems can be. When I call customer services to report a fault with my broadband connection, for example, only to be told that all their systems are down and they can't help me.

Is it really asking too much that people who build software should care that the software they build is reliable? Apparantly so. Those of us who really do care are evidently in the minority. This may be partly due to ignorance - the majority just aren't aware of practices and techniques that make more reliable code not only achievable, but actually cheaper than the unreliable code they're currently churning out. It's also perhaps partly due to the fact that it's rare to find a software development organisation with a pro-quality culture. Deliver high-quality software late and they'll roast you. Deliver crappy software on time and they'll throw you a party. What kind of message does that send out? Kids who get candy when they poo on the bathroom floor are going to go right on pooing on the bathroom floor. (A delightful analogy, I'm sure you'll agree.)

By reinforcing a hit-the-deadline-at-all-costs culture, managers push their projects into a cycle of pain where "on time" deliveries are really nothing of the sort. Sure they hit the deadline, but they'll need another 3 months to fix all the bugs and make the software good enough for actual use. That's not "on time", folks - that's 3 MONTHS LATE! And the reason it's 3 months late is because bugs cost exponentially more to fix than to prevent through effective pro-quality practices like test-driven development, pair programming, code inspections, requirements walkthroughs and so on.

Rant over.

Anyway, that was all just a cunning ploy to remind you about the icareaboutsoftware.org pledge. There are about 20 or so spaces left in the first 100, whose signatures (and links) will appear forverer emblazened on the home page. If, like Grady Booch, Brian Marick, Steve Freeman, Ivar Jacobson, Cem Kaner, Capers Jones, Tom Gilb and many more, you give a hoot about the value and quality of the software you help to create - in whatever capacity - then here's your chance to stand up and be counted.

When we get to 100, a logo and accompanying artwork will be developed and released under a Creative Commons license so you can use them on t-shirts, caps, kinky underwear and scuba gear to help spread the good word.
Posted 13 years, 1 month ago on October 16, 2007