The Seven Wastes in Software Development

This is the first in a series of posts around techniques and mental models that are useful in managing and improving a software development process. I am not trying to say that any framework, process or mental model is best, every development environment is different and has its own challenges. A solution that works at one company may not work that well at yours.

In this post, I want to explain the concept called “The seven wastes” and explain how this can be useful when looking for opportunities to improve your software development process.

The seven wastes is a concept from the Toyota Production System, if something is not perceived as of value to the customer then it is considered waste. One easy way to think of what is considered to be of value is anything the customer would gladly pay for you to do. The original seven wastes are the following.

The concept was extended to software development by Tom and Mary Poppendieck and slightly altered to be the following.

1. Partially Done Work
2. Extra Features
3. Delays
4. Handoffs
5. Context Switching
6. Defects
7. Extra Processes

I will explain each of these and give examples that are relevant to creating software.

Partially Done Work

This can be a huge waste in software development, this is represented by development work done but has not been released. Software is written so it can be used by its users, writing code costs time and money so if it is not being used then it is considered wasteful. Types of partially done work are.

1. Software that is complete but not released
2. A project that was in progress but then development stalled leaving incomplete code and features.
3. Features that are in some stage of the development process e.g development or testing.

The dollar impact is quite obvious, a business cannot forever write software without releasing it. This money would have been better left in the bank earning interest. The code itself without being released loses value over time, customer needs may be changing making the work less relevant, the developers may forget what they wrote so to get back into developing takes longer to get back up to speed. Technologies slowly become out of date so if it was not released for a number of years there may be compatibility issues that need to be fixed.

The solution to partially done work is to release your software earlier. There will always be an amount of partially done work, however, efforts to make that as small as possible will yield benefits.

Extra Features

Creating features that people do not use is wasteful, the most obvious is the cost and time spent on developers creating these features. However extra features make the application more complex with more lines of code than what is necessary. Extra documentation is needed and extra testing to ensure that these unused features still work.

With many applications being server-based and the abundance of telemetry libraries and logging available telemetry can be added to an application to see how much particular features are used. Unused features could be removed, thus making the code simpler. There could be abstractions or architectural ugliness that could be removed if particular features no longer exist.

Delays

Customers do not want to pay for developers having to wait, laptops rebooting, slow networks, builds taking a long time. If you sent an invoice to a customer that only contained the following your customer would be angry.

• 2 Hours waiting for my laptop to get fixed
• 1.5 hours waiting for the build to complete
• 6 days waiting for sign-off from the department head before being able to deploy

They would rightly ask, “Why am I paying you to do nothing?”. Of course, delays will occur but could they be decreased? Are there other types of delays in your organisation that you wouldn’t want to itemize on on your bills?

Another form of delay is waiting for other people. These could be for approvals from management or support tickets for changes to an environment. Would your customer be willing to pay for developers waiting on support tickets to complete?

Reducing delays means that developers can work with fewer interruptions and the total time required to release a feature will drop which will also reduce your amount of partially done work.

Handoffs

For a feature to be developed how many people/teams does it need to go through? Is it one or two or is it fifteen to twenty. The more and more handoffs you have the more delays occur and the greater chance of errors sneaking in. Also with more handoffs, you need to spend more time communicating what is happening. Meaning that could be adding extra delays just by trying to keep everyone informed.

Can you try and reduce the number of people that need to interact with a feature before it is released. Could you remove a handoff with no negative impacts?

Context Switching

This is when someone is working on a task and then has to switch and start doing a different task and then go back to the original task and continuing to switch between them, this has been found to be less productive than doing a task until completion and then switching to the next task.

Examples of context switching could be

• Replying to messages part way through a task
• Working on a feature and then switching to fix an issue that has popped up.
• Working on two separate features during the day.
• Getting distracted by noises or conversations and then returning back to your work.

The more switches you make the harder it is to get things done and to get into states of deep concentration.

At a team level, one way to reduce context switching is to try and reduce the number of items that are being worked on at the same time. All your stakeholders may be happy that their feature is being worked on, however, a development team working on six things at once is not going to be as effective in the long run compared to working on fewer tasks at once.

At a personal level one good way to help reduce context switching is the Pomodoro technique, this is where you have a timer set to 25 minutes and you work non-stop without changing tasks until the task is done or the time is up, you then take a 5 minutes break and then start again. It can feel hard at first focusing on only one thing but you end up getting into a groove where it gets easier and you start to see a list of completed tasks. Also, the act of having to decide what you are working on for the next 25 minutes without distraction helps plan your day and focus on what is most important.

Defects

This is where software was done in a way that was incorrect then someone needs to go back and make a fix, if it was right the first time then someone wouldn’t have to go and spend time on making a fix and then having the code go through the test and release process.

I am not saying that all defects can be removed but if the number of them is reduced and the detection of them occurs earlier then less developer time is wasted.

Extra Processes

Every business has processes, but are there processes that yield no tangible benefit to the software being released? These could be forms that need to be filled or sign-offs from particular people in the organization.

Quite often a process or policy will be created due to an issue that occurred in the past but then it stays in place for years. No one exactly knows why we need to do it but it is still followed.

A question to ask is what would happen if that process was ignored? How long would it take for an issue to occur by missing that process? A lot of people would argue that if their team stopped doing their daily stand-ups then things will start to go wrong in a couple of days. That is an indicator that this is a useful process. The flip-side could be a monthly status meeting, does anything crucial come out of the meeting, could half the participants stop going to the meeting? Try and look for processes/procedures in your daily/weekly/monthly work and have a hard look and see if any can be missed.

Over Processing

This is I feel was missed by Tom and Mary Poppendieck. This was one of the original seven wastes, this is where too much processing effort is put into a product. E.g if the size of a wheel needed to be accurate to within 1/100th of an inch but effort is put into making it accurate to within 1/10,000th of an inch that extra accuracy may not be worth the effort and the extra time and cost to get to that would be considered wasteful.

The equivalent in software development would be over-optimizing, putting too much work into improving the performance of a feature. For example, if I had a web service and I was working on improving the latency I could spend a day to get the response time of 200ms down to 20ms. That would be a good improvement if that is a change that improves the visible performance of the system. However, if I then spend a week to get it down from 20ms to 18ms that gain most likely is not worth the effort.

This, however, is very context-dependent, it all depends on what the customer is willing to pay for. If this web service was used in a user interface then the user wouldn’t notice any speed improvements once response times are less than 100ms. However, if the customer has a requirement that all web services must respond in 15ms or less (maybe it is a high-speed trading platform) then the further optimizations are of value.

This is not just about latency, optimizing for memory usage or startup times or any other non-functional requirement may hit a point where the gains aren’t of value to the customer.

Conclusion

This is a summary of some types of waste that can be found in software development, different organizations will suffer in different ways from these issues. It is a fact of life that nothing is ever perfect, it is not meant to be a doom and gloom view of things, to get to zero waste would be impossible. Plus, as you try and remove these types of waste new examples will become visible.

These are best viewed as a list of improvement opportunities you could undertake when you are looking to improve your software development process. Use these as a reference when looking for opportunities to improve the way you work in your organization.

So when you and your organization are looking for ways to make your work better try looking at your world through the perspective of the 7 wastes and see if opportunities for improvement can be found.

Originally published at http://graemejmuir.com on October 27, 2019.