Writing Software as a Kaizen Event

In the past, most developers’ approach to code is that you should write it once and hopefully never have to debug or revisit it again. This stems from the traditional waterfall approach of software development where we were trying to completely describe the entire system up front perfectly. Change was bad and bugs were not accounted for and left for the end.

The Agile movement ushered in the first change to this mentality. Agile introduced the concept of refactoring, or writing your software once and then revisiting it (often if needed) and restructuring its internals for improvement (without changing its external outputs). Refactoring is a core tenant of test driven development, where you are encouraged to refactor each method you write at least once.

The Lean Manufacturing movement is built around the concept of Kaizen, or Japanese for “improvement” or “change for the better.” Last week at the first even Lean and IT summit in Paris, France, I heard once or twice about the concept of writing code as a Kaizen event. Software Kaizen goes a step further than refactoring.

The Lean guys were talking about Kaizen as the removal of waste by the improvement of your own work. It is about understanding waste derived from your own decisions, looking at the unnecessary costs created by our wrong assumptions and decisions. The Lean guys spoke about how Kaizen is cultural shift that gets people thinking.

While refactoring addresses each individual method, Software Kaizen takes a much broader approach and looks for waste in your entire work. A lot of time we developers build features and stuff that are not needed. Where did you create a library that you only call once in the name of “maintainability?” Where did you make something unnecessarily complex in the name of “extensibility?” Where where your assumptions incorrect and caused problems or ambiguity in your code? When have you over engineered a feature? Refactoring only partially addresses this, we’ll go in on a regular basis and refactor a few complex methods, but we rarely ask ourselves if we need that entire method in the first place, or an entire feature. Software Kaizen asks us to look at our code and asks us why did we do it this way, with a “cut first” mentality. It challenges the assumptions we made at the time we wrote the code.

Traditional waterfall approached code as something you should write and be perfect the first time and only revisit it when you find bugs. Agile encourages refactoring your methods for improvements in the way it runs and reads internally. Software Kaizen encourages looking your system and looking at the choices you made in the name of maintainability, extensibility, etc, and ask yourself where you were wrong. Software Kaizen focuses on approaching your code knowing you are going to change it often. In the past we fought change, Software Kaizen embraces change as part of the process.

Give it a try, it is harder than it seems. (“Of course I need that really really complex method, I may one day port this code to a Mainframe!”) Good luck and happy coding.