Wastes of software development

소프트웨어 개발에서의 낭비¹

Partially done work

Partially done software development has a tendency to become obsolete, and it gets in the way of ther development that might need to be done. But the big problem with partially done software is that you might have no idea whether or not it will eventually work. … Partially done software development can carry huge financial risks. Minimizing partially done software development is a risk-reduction as well as a waste-reduction strategy.

Extra Processes

Do you ever ask, Is all that paperwork really necessary? Paperwork consumes resources. Paperwork slows down response time. Paperwork hides quality problems. Paperwork gets lost. Paperwork degrades and becomes obsolete. Paperwork that no one cares to read adds no value. … If you must produce paperwork that adds little customer value, there are three rules to rememer: Keep it short. Keep it high level. Do it off line. …

A good test of the value of paperwork is to see if there is someone waiting for what is being produced. … Consider writing customer tests instead of requirements. In general, delay documneting the details of desired features until the iteration in which they are implemented.

Extra features

Developers might like to add a new technical capability just to see how it works. This may seem harmless, but on the contrary, it is serious waste. Every bit of code in the system has to be tracked, compiled, integrated, and tested every time the code is touched, and then it has to be maintained for the life of the system. Every it of code increases complexity and is a potential failure point. There is a great possibiliy that extra code will become obsolete before it’s used; after all, there wasn’t any real call for it in the first place. If code is not needed now, putting it into the system is a waste. Resist the temptation. (see also YAGNI)

Task switching

Assigning people to multiple projects is a source of waste. Every time software developers switch between tasks, a significant switching time is incurred as they get their thoughts gathered and get into the flow of the new task. … The fastest way to complete two project that use the same resources is to do them one at a time.

Waiting

One of the biggest wastes in software development is usually waiting for things to happen. … So what’s wrong with waiting? Delay keeps the customer from realizing value as quickly as possible. When critical customer need arrives in your development organization, the speed with which you can response is directly related to the systemic delays in your development cycle.

Motion

When a developer has a question, how much motion does it take to find out the answer? … Development is an activity that requires great concentration, so walking down the hall takes a lot more time than you might think. …

People aren’t the only things that move - various artifacts mvoe also. Requirements may move from analysts to designers, and then design documents move from designers to programmers, and then code moves from coders to testers, and so on. Each handoff of an artifact is fraught with opportunities for waste. The biggest waste of all in document handoffs is that documents don’t contain all of the information that the next person in line needs to know.

Defects

The amount of waste caused by a defect is the product of the defect impact and the time it goes undetected. A critical dfect that is detected in three minutes is not a big source of waste. A minor defect that is not discovered for weeks is a much bigger waste. … Thus, the way to reduce the waste due to defects is to test immediately, integrate often, and release to production as soon as possible.

Footnotes

1. Chapter 1, Lean software development (book) ↩