Another Look at Lean

on Sunday, February 26, 2012
On Saturday 11th of February I was attending to Application Lifecycle Management course at JAMK. There Heikki-Pekka Noronen was giving a lecture titled as "A Lean Perpective". The lecture gave me new ideas about lean.

I haven't investigated lean principles very deeply, but before the lecture I had quite solid idea about what lean is roughly about. Especially the "eliminate waste" was a familiar concept to me, but after the lecture I saw it in somewhat new light. I had become skeptic towards my previous impression of waste.

In HP's slides it was said that "waste is everything that does not add value" which is in my opinion a great way to summarize the definition. What really hit me were the things listed after this definition.

  • Partially done work (such as defects, untested code, unfinished or unused documentation..)
  • Slow internal communication
  • Unclear requirements (they truly are partially done, are they not?)
  • Queues, in all of their form

I'm unlikely the only software developer in the world who has been in such situation where stakeholders are asking what would be the fastest and cheapest way to implement some feature. I have thought that it's lean to think about some "duck tape quick-fix" in order to do something quickly as possible. But then again if the feature would be done properly with sustainable architecture, would it add value? First it was easy to think about maintainability, stability and other technical aspects and why it would always add value to go for proper architecture. Instead of always going for sophisticated solution, another kind of approach has had positive effects on our projects.

Value of proper architecture versus quickly implemented duck tape fix has usually a strong correlation between how temporary the outcome of the project is. This isn't always the case, but in our software development we have noticed this quite often being true.

If some web based application or environment is used only for short duration, it has been perfectly fine to patch, for example, some ugly user interface issues with bubble gum. It doesn't matter if the underlying core will eventually change and thus our quick-fix would then break because it's dependent of that core functionality - the environment is already deactive and has no usage. This is also the case if the outcome of the project is used only once and has no value for other projects. The shorter lifespan the outcome has, more wild and unstable implementations can be introduced without having to worry about long term support and stability.

If we are creating long term environments, products or applications, decision to patch something quickly would lead to unstable environment, more errors, more maintenance and unhappy customers when things fall apart. Also if we would create something that will probably be used in other projects too, it makes sense to invest more time to create proper architecture so that the next time the same outcome is used, it will work without hiccups.

I guess the most important message in the lecture for me was that it isn't necessarily against lean principles to test code thoroughly, write extensive documentation and design proper architectures. It's just the matter of what creates value and what does not.

This blog post was written from software developer's technical point of view. If you want to read about lean from more communicational and social point of view I recommend you to take a look at this blog post by Esko Kilpi.