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.
Stephen Forte sits on the board of several start-ups including Triton Works. Stephen is also the Microsoft Regional Director for the NY Metro region and speaks regularly at industry conferences around the world. He has written several books on application and database development including Programming SQL Server 2008 (MS Press).
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.