Waste #2: Extra Features

Welcome to episode three of our series "The Seven Wastes of Software Development." In episode one, we introduced the concept of eliminating waste from our software development efforts. Waste elimination can be traced all the way back to the the mid-1900's, the birth of lean manufacturing, and the Toyota Production System (TPS). This is how Taiichi Ohno, the father of the TPS, described its essence:

All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes. [1]

Read the other parts in this series:

• The Seven Wastes of Software Development - Introduction
• Waste #1 - Partially Done Work
• Waste #2 - Extra Features
• Waste #3 - Relearning
• Waste #4 - Handoffs
• Waste #5 - Delays
• Waste #6 - Task Switching
• Waste #7 - Defects

In this episode, I'd like to focus on another thing that slows us down: extra features. Extra features come in many shapes and sizes:

• Occasionally a product stakeholder will have a "pet feature" that he/she insists will be included in the product. While it may be a clearly wrong decision economically, he/she will use role power to ensure that it is included.
• Sometimes long feedback cycles will cause features that have become obsolete to live longer than they ought.
• Believe it or not, developers still slide features in just to try out the latest hip and trendy technology. This phenomenon is also known as RDD - Resume Driven Development.
• There's also the conscientious developer that "just knows" that the customer is going to need "Feature X," even though the customer hasn't specifically asked for it, and they dutifully add it to the product.
• And of course there's always the feature that sounded good to both customer and developer alike, but six months into the product's production lifecycle no one has used it!

Looking back to the seven wastes defined by lean manufacturing, we'll find that the parallel to this waste is overproduction. Many have stated that Taiichi Ohno considered overproduction to be the worst of the seven wastes, although I have not found a proper citation to that effect. With that said, let's consider whether or not this may be true. If you examine the other six wastes, you'll see that they are primarily concerned with how we produce product. Extra features (or overproduction) is primarily concerned with what we produce. In fact, it stands to reason that if we are wasteful in how we produce necessary features, we will be wasteful in the same way in how we produce extra features. Thus, producing extra features actually drives an increase in all of the other wastes!

Not only that, but extra features have their own share of costs. According to the Poppendieck's [2], all extra code in our systems:

• must be tracked
• must be compiled
• must be integrated
• must be tested (every time the code is touched!)
• must be maintained (for the life of the system!)
• increases complexity
• adds a potential failure point
• likely will become obsolete before it's used

It's quite clear from this analysis that extra features definitely slow us down. How can we guard against them?

Our first best weapon against extra features is a short feedback cycle. Frequent product demos will expose features that we're working on that our customers no longer believe will give them a competitive advantage. Even better than frequent demos are frequent production deployments. Getting the software in the wild on a regular basis and then tracking feature usage can easily expose features that are not needed. Removing features from the system will reduce the complexity, maintenance load, and likelihood that things will go wrong going forward.

Our second weapon against extra features is a healthy dose of "YAGNI." YAGNI stands for "You Ain't Gonna Need It." This phrase represents one of the original principles of eXtreme Programming, that of only adding functionality when it is necessary to meet a clear and present need of the customer.

Wikipedia's article on YAGNI [3] provides the following useful summary of the disadvantages of extra features:

• The time spent is taken from adding, testing or improving necessary functionality.
• The new features must be debugged, documented, and supported.
• Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
• Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
• It leads to code bloat; the software becomes larger and more complicated.
• Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
• Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.

So, to summarize, let's consider this enlightning quote from Gordon Bell:

The cheapest, fastest, and most reliable components of a computer system are those that aren't there.

That's all for this episode of "The Seven Wastes of Software Development." Stay tuned for the next installment: Relearning.

References

[1] Ohno, Taiichi. Toyota Production System: Beyond Large Scale Production. Productivity Press, 1988.

[2] Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.

[3] You Ain't Gonna Need It: http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it

Other articles in this series:

• The Seven Wastes of Software Development
• Waste #1: Partially Done Work