Cook Computing

Driven Round the Benz

October 12, 2005 Written by Charles Cook

It depresses me that after a number of years in software development I don't experience much change in the way software is developed. In essence, do some design, knock up some code quickly and then spend a much longer period of time fixing bugs. As well as being soul-destroying its also hugely unproductive. These were my tangential thoughts after reading Driving You Round the Benz in the Independent:

So where did it all go wrong for the maker of "the best cars in the world"? Back in the 1990s, Mercedes manufacturing processes were old-fashioned and cost-intensive. The result was great quality - at great cost. The upshot was also that Toyota, an exemplar at efficient "lean" production, took less time to make a car than Mercedes took to rectify each fully assembled car. If Mercedes was to stay in business, this could not continue.

Except that great quality was never there to begin with in many software products. Where are the Toyota's of the software world we can learn from? TDD seems to offer some hope and I noticed Keith Ray has some links to interesting Uncle Bob pieces on TDD: one, two, three. Martin addresses the issue that it is tempting to fall back into the bad old ways when schedule pressure mounts:

I have been consulting for a number of teams that have adopted Agile Methods, including TDD. One common issue I have found is that developers drop the discipline of TDD in the face of schedule pressure. "We don't have time to write tests" I hear them say. Before I comment on the absurdity of this attitude, let me draw the parallel. Can you imagine an accounting department dropping dual entry bookkeeping because they've got to close the books on time? Even before SARBOX such a decision would be such a huge violation of professional ethics as to be unconscionable. No accountant who respected his profession, or himself, would drop the controls in order to make a date.

That is not to say that accountants don't take shortcuts in the face of schedule pressure. They might not break down all the categories. They might not do all the what-if scenarios. They might bundle some things together that should be split. In other words, they might reduce scope. But would they drop the dual entry practice?

Consider a surgeon who, under schedule pressure, decides not to scrub. Consider a pilot who, under schedule pressure, decides not to go through the checklist. There might sometimes be emergency situations that justify a decision like that; but they had better be extremely rare, life-or-death situations. Even then, the decision is more likely to make things worse than better.