Kaizen and Software Engineering

Kaizen and Software Engineering

Kaizen is a very interesting approach, also in the software industry. On Wikipedia you’ll find the following description of Kaizen:

Kaizen is a Japanese word adopted into English referring to a philosophy or practices focusing on continuous improvement in manufacturing activities, business activities in general, and even life in general, depending on interpretation and usage.

Kaizen aims to eliminate waste, to improve the process or activities (techniques). I heard about Kaizen the first time at an economic course, and I found the Muda (seven wastes) very interesting. I tried to find locations or situations where you can detect such wastes:


Overproduction happens each time you engage more resources than needed to deliver to your customer. For instance, large batch production, because of long change over time, exceeds the strict quantity ordered by the customer. For productivity improvement, operators are required to produce more than the customer needs. Extra parts will be stored and not sold. Overproduction is the worst Muda because it hides or generates all others, especially inventory. Overproduction increases the amount of space needed for storing raw material as well as finished goods. It also requires a preservation system.

Overproduction happens then, when you don’t follow the YAGNI principle. Don’t try to make assumptions about the future or the customers. Just produce the things as simple as possible.

Unnecessary transportation

Each time a product is moved it stands the risk of being damaged, lost, delayed, etc. as well as being a cost for no added value. Transportation does not make any transformation to the product that the consumer is supposed to pay for.

Don’t build chatty interfaces, make use of the coarse-grained interface pattern.


Inventory, be it in the form of raw materials, work-in-progress (WIP), or finished goods, represents a capital outlay that has not yet produced an income either by the producer or for the consumer. Any of these three items not being actively processed to add value is waste.

Deliver early and often. Don’t wait at the end of the project to deliver the whole software at once. If you deliver your software earlier and often, you will receive more feedback and so the costs to fix bugs will reduce. Also the customer will be happier because he could use much earlier important parts of your software and he could observe better the progress of the software project.


As compared to Transportation, Motion refers to the producer or worker or equipment. This has significance to damage, wear, safety. It also includes the fixed assets, and expenses incurred in the production process.

Good hardware and a good chair is very important to be productive. Slow computers are just horrible to work with and a bad or cheap chair is not very good for the health of the software engineers. If the software engineer feels comfortable, he’s much more able to be concentrated or work longer.


Whenever defects occur, extra costs are incurred reworking the part, rescheduling production, etc.

Reduce Defects. Unfortunately there doesn’t exists a programming language where it isn’t possible to make no errors. So testing is absolutely necessary. Do unit testing with or without TDD, but a modern software project should have tests (unit tests, integration tests or acceptance tests, etc.). Without tests you don’t have a safety net (regression tests) if you change something in your project. One of the worst error a customer could find is one which he already found and was fixed.


Over-processing occurs any time more work is done on a piece than what is required by the customer. This also includes using tools that are more precise, complex, or expensive than absolutely required.

Overengineering and Patternoholics are a danger to do more than it is necessary.


Whenever goods are not in transport or being processed, they are waiting. In traditional processes, a large part of an individual product’s life is spent waiting to be worked on.

Slow computers where you have to wait for a build step or just for the compiler are an unnecessary waste. Also if you wait for an answer from your customer or an other teammate. Don’t wait, make a follow-up, make a phone call or write an other mail. Also don’t let the others wait. If you receive an email, answer it or write a short email to say that you will response later, so that the other knows, that you saw his mail and you planed to response him.


One important question is: “Do you add value to your solution, product or service which the customer is ready to pay for?” This question or view isn’t new. It focus all the actions in software engineering on business value, the value which the customer pays for. To reduce the waste you have to improve (Kaizen) your code, methods and communication with others. The seven wastes are a help to find locations or situations where waste could happen.

10 thoughts on “Kaizen and Software Engineering

  1. Apparently, there doesn’t exist a human language where it isn’t possible to make no errors, either.

  2. Pingback: software | SOFTWARE
  3. I liked it. So much useful material. I read with great interest.

  4. Pingback: Destillat KW44-2009 | duetsch.info - GNU/Linux, Open Source, Softwareentwicklung, Selbstmanagement, Vim ...
  5. Interesting! I didn’t know about Kaizon before reading this post. I am going to have a bit of a play with it and hopefully it will be useful in the future…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.