clean firetrucks

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…

tidy gemba

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…

Update, 24.10.04
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.

Design for testability

I just found Michael Feathersrant about designing for testability. I couldn’t agree more with his sentiment!

A couple of years ago I worked with a team that had exactly the problem Michael describes. Many of the classes were nearly impossible to instantiate in a test harness, and many of their methods couldn’t be tested without dire consequences for the development environment. Refactoring in the subsystems that contained these classes was also impossible, because of the unpredictable side-effects incurred by doing almost any method call. In the end, after months of frustration, we decided to very carefully and incrementally throw away those classes and replace them with something testable. In fact, that large-scale refactoring was never finished (due to circumstances outside the team’s control), but the improving code definitely “felt” better.
Continue reading

everything in its place

A couple of weeks ago I finished reading Gemba Kaizen by Masaaki Imai. Just like all the other books on lean manufacturing, I found it extremely rewarding and thought-provoking, while at the same time being somewhat longer and more repetitive than I might have wished (the second half comprises an interminable list of case studies, many of which add very little to the value of the book).

The main idea I took away from the book was that of 5S. This is basically rigorous and institutionalised house-keeping (translated as Sort, Straighten, Scrub, Systematize, Standardize). The idea is that an untidy or disorganised workplace can contribute significantly to reducing the throughput of value for the customer.

Can this concept be applied to software development? I believe so. All our tools have to be readily accessible when needed. Our codebase, workspace and CM system should all be well-organised, and should contain nothing that isn’t needed to add value or promote flow. Our build should be clean and automated, and driven only from components that are CM-controlled. And when we’re working as a team, all our processes and techniques should be standardized so that each person’s actions are understandable by all.
Continue reading