In Quantify the cost of the things you wouldn’t have had to do, if only… Dave Nicolette attempts to calculate the overall cost to his project of a single defect. He arrives at a total of $8,712.50! First, there’s the time spent by the latest developer who got caught by the bug; then there’s the time spent by his two teammates when they helped him debug and fix it; and then there’s the multiplier for all the times this same defect had occurred, but gone unfixed, during the previous two years.
Dave’s figures are compelling, and quite possibly fall on the conservative side – for example, there may have been occasions in the past in which the application hung up during testing, but no-one reported the problem.
I prefer to leave the figure in developer-hours (102.5 in this case), so that we have an indication of the amount of backlog that wasn’t addressed due to this bug: the broken window cost the project almost three developer weeks of progress! If that time had been used to add just one more story, or to release just a little sooner, I wonder what the knock-on costs of this bug would turn out to be, in terms of lost opportunity revenues etc…
Seth Godin suggests that Clean Firetrucks are a sign that the firemen are focussing on the wrong things: instead of washing their vehicles they should be out preventing future fires. In my opinion – and who am I to decide how a fire station should be run? – they should be doing both.
If I were the manager of a fire station, I would be looking to clean firetrucks as a sign of many positive things – primarily that the lean notion of 5S was being applied. A clean, tidy, well-maintained workplace is essential to high throughput. Problems can be detected sooner, maintenance is easier and quicker, and morale is generally higher. Not to mention the firemen’s professional pride: who wants to be seen rescuing a puppy from a burning building, only to take it back to a vehicle that has ‘also available in red’ scrawled in the dust on the back?
In software development we have an additional workplace: our code. When we fail to keep it clean and tidy our productivity falls and our systems’ adaptability falls even faster. (This is where the exponential cost-of-change curve originates – untidy gemba.) When I see dirty firetrucks in a software shop, I know to expect low productivity, high turnaround times on feature requests, and defects in abundance. Broken windows, as the Pragmatic Programmers put it.
Lean thinking says that time spent keeping gemba tidy repays itself many times over in terms of increased throughput and sustainable pace. And besides, I happen to like clean firetrucks…
Last week Will asked me how a well-factored, defect-free application could quickly degenerate into a haphazard pile of partially complete, mostly working features. I replied that the answer lies partly in what the Pragmatic Programmers call broken windows.
My new manager wanted to give me some background reading to do today. So we went to the place on the fileserver where all the documents are stored, so that he could “show me around”. Naturally, we found loads of documents, but all of them were either obsolete or out of date. We never found the file he was looking for, and in the end I had to borrow a printed copy from someone’s desk.
We both wasted 15 minutes because the workplace (in this case, the filestore) was untidy. House-keeping is never a waste of time…
On reflection, this is probably a case of broken windows. One person leaves a folder untidy, and that gives implicit permission for everyone else to do the same. Because everyone can see that no-one cares.