We need to talk about waste in software development.
I think about waste every single day. Actually, I think about it multiple times a day.
I think about it when prioritizing my tasks, when talking to coworkers, when doing code reviews and when coding. I think about it a lot when designing.
I am referring to “waste” in a very specific context, however. In lean philosophy, waste is referred to as the Japanese word muda. Starting with a simple definition:
From an end customer’s point of view, value-added work is any activity that produces goods or provides a service for which a customer is willing to pay; muda is any constraint or impediment that causes waste to occur.
“Waste” here is anything that does not bring direct customer value. It is something that the customer is not willing to pay for.
The lean philosophy’s main rule is to eliminate waste.
Eliminating waste is also the basis of the personal philosophy I have come to believe when building products, even before I read anything about lean software development.
Today, it serves to me a compass, a very reliable rule-of-thumb that helps me allocate my time on a day-to-day basis. It also helps me to bring clarity to the team of developers working with me.
I hope I can help give you a new appreciation of its principles.
Sources of Waste
Note that the definition above carries more meaning that just saying something is a “waste of time”. It is not just about efficiency and doing more with less time.
It is about seeing every single activity from the lens of the customer, and judging your activity’s value from the point of view of the customer.
Not all waste is possible to eliminate. Some waste is necessary for the proper functioning of the organization.
If you ask your customers, I am sure they are not willing to pay for your time waiting for your build to run. However, it is still necessary to build code. Even if it cannot be completely eliminated, it can be optimized.
In this same direction as code build time, test run time and code review turnaround time are all sources of waste. No customer is willing to pay for that.
While these are pretty obvious examples in the day of a developer, these are far from the most dangerous sources of waste. If you ever had your project canceled after months of work without any of your code even seeing the light of day, you know what I am talking about.
In the next posts, I will talk about the most pernicious sources of waste, at least from my own experience.
We will start from the top, the source of many true software developer horror stories: building stuff that should not have been built in the first place.