Waste in Software Development

 In my community, we love to say the word waste - from lean - out loud. There isn’t a meeting without mentioning it at least once, and when it is mentioned, the phrase we have to eliminate waste follows. This is something that is very easy to say: eliminate waste. Go to a meeting, and when somebody says waste, jump in and say: ”we have to eliminate the waste!”. People will look at you and nod. But I’m afraid it is not that simple in most of the cases. Eliminating something is way easier than understanding a system, finding the waste and acting properly. Again, acting properly. Immediate elimination seems easy, but most of the times it solves only the local issue, and has a short term effect. So, please stop saying ”we have to eliminate the waste!”, and start saying ”we have to study our system, find out what kind of waste we are dealing with, and where it is generated!”

So, according to Taiichi Ohno - inventor of the Toyota Production System (on the right) -, there are three kinds of waste, which slow down the process by increasing the lead time:

1. Muda
2. Mura
3. Muri

They are very well explained in the car manufacturing context by Ohno, so I’ll put them into a software development context.

Muda

Muda is an activity in the process which doesn’t add value to the product. When we are talking about waste we are actually referring to muda. According to the Toyota Production System muda falls into seven major categories.

Corrections

In other words: defects or bugs. They are the result of poor code quality. Fixing the defects or setting goals on the number of defects in the system won’t eliminate this kind of waste. Instead, it will hide them, or transfer them to a different place. This kind of waste is a well known sign that something is wrong in the process. The right move here is to find the place which is malfunctioning and fix it.

Over-production

Over-production happens when an organization does not understand the change in the customer demand and therefore produces too much or too early. In other words, you have an existing product, and you are adding features to this product, but they no longer provide value to your customers or they cannot use them at all. For example, adding features to a website which runs only in Internet Explorer.

Over-processing

This kind of waste is generated when we add things to the product that the customer didn’t ask for. Developing these things takes time and money, they unnecessarily increase the complexity of the system, and increase the possibility that new problems will appear. For example, your customer asks for a simple website and you deliver a complete JavaEE solution when a static website have done the trick.

Transportation

The transportation waste is generated when materials are moved around the factory. Moving materials is expensive and dangerous. Fortunately, we don’t move materials around the office, but we move a lot of information through several unnecessary middlemen. This can take some time and in the meantime the information can change, get lost or become obsolete. For example, you cannot talk directly to the other teams or cannot download logs from the production system.

Motion

Motion is very similar to transportation, but it is about the people. This waste is generated when the people have to make rounds in order to get the job done, they are using the wrong tools, don’t have all the information to do the job, or get reassigned. For example, you have to use gedit for javascript development, because your company doesn’t want to buy you a more suitable development environment.

Inventory

Inventory waste is generated when the output of a phase cannot be immediately used by the next phase, or the finished product cannot be delivered to the customer. For example, your architects are writing you studies about what the system should support next year, but the developer teams cannot pull anything from them for months.

Waiting

Waiting is a very tricky one, because its quantity is highly subjective: I would say that I’ve been waiting for a long time now after waiting 3 or 4 hours, but my girlfriend would say this after 20 minutes. By definition, the waiting waste is generated when a team member is idle, because he or she cannot do anything at all. For example, testers are waiting for the new package installation to be finished. They cannot do anything (testing, improvements, etc.), because their system is being installed. Pulling a work item from a different queue doesn’t make too much sense either. The installation will definitely be finished before they can finish the pulled item, and finishing the item will delay the real testing work. So they stay idle instead.

One more thing: administration

This kind of waste was never mentioned by Ohno, I made it up myself. The administrational waste doesn’t really fit into any of the categories above, because it generates all kinds of waste. It is generated by the organization itself, mostly by management. For example, a status meeting has no value to the customer (over-processing), it keeps people away from their jobs (motion), and the distributed information changes all the time (transportation).

Muri

Muri causes overburden by putting unnecessary pressure on people and processes. For example, asking a junior team member to implement a brand new feature, or using a system which served 1,000 customer requests a day previously to now serve 100,000 requests.

Mura

Mura refers to inconsistency, unevenness or unbalanced demand situations in the system. For example, the workload is usually not that high at the beginning of the project, but always becomes high at the end of it. Unfortunately, Mura is a bit underrated, but it is important to know that it generates Muda and Muri. For example, when the demand increases, most of the people start to make mistakes (correction waste), forget important details (transportation waste), have to report more (administration waste) or get reassigned (motion waste). When the demand is lower, we tend to pile up work (inventory waste) or do what we think is necessary (over-processing waste).

Final thoughts

As you can see, it is crucial to understand the demand. Once you understand it, you can start looking for the tasks which generate waste in your process and apply the right technique to eliminate them. You might have realised that there are no suggestions in this post on how to eliminate a certain kind of waste. It is intentional: I strongly believe that there is no generic solution in eliminating waste, and without knowing the context even a seemingly innocuous idea can cause a lot harm of the system.