IEEE Software, Vol. 14, No. 6, November/December 1997
Achieving Leaner Software
Software developers and managers claim that they understand the benefits
of keeping their software simple, but industry reports indicate otherwise. Developers,
managers, marketers, and end-users continue to stuff so many features into already-bloated
products that one of the elders of the software industry has publicly pleaded for leaner
software (Niklaus Wirth, "A Plea for Lean Software," IEEE Computer,
Whether the software pudginess originates externally, from excess
features, or internally, from overly complex designs and implementations, pudgy software
takes more time to design, code, and debug than simpler software. Cost per line of code
and defect rate per line of code increase as software size increases (Steve McConnell,
"Less is More," Software Development, October 1997). Larger software
requires larger teams and all the inefficiencies that larger teams entail. At this point
in history, when "short time to market" is a rallying cry for almost all
software projects, project teams should be looking for ways to make their software leaner,
less complex, and easier to build and deliver.
Several practices can help keep porky software from bingeing on excess
Software Requirements Dieting. Early
in the project, the most effective part of a lean software diet is a big helping of
requirements scrubbing. Take your carving knife in hand and go over the software
requirements specification with the following aims:
- Trim all features that are not absolutely necessary.
- Simplify all features that are more complicated than absolutely
Entirely removing a feature is a powerful way to save time because you
remove every ounce of effort associated with that feature: specification, design, testing,
documentationeverything. You also eliminate all the possible interactions between
that feature and the softwares other features, which reduces effort even further.
The earlier in the project you remove a feature, the more time you save.
The ultimate success of requirements scrubbing depends on
follow-through. If you begin with 100 features and sweat the software down to 70 features,
you might well be able to complete the project with 70 percent of the original effort. But
crash fitness programs are risky. If you trim the list down to 70 features only to
reinstate the omitted features later, the project will likely cost more than if you had
retained the entire 100 features the whole time. Adding features late in the project is a
sure way to increase software complexity because, rather than having the built-in
compatibility with the rest of the software that early features have, late features must
be integrated with the rest of the software as special cases, which contributes enormously
to complexity and software bulkiness. Late features typically cost from 50 to 200 times as
much to implement as they would have cost if added early in the project (Barry W. Boehm
and Philip N. Papaccio, "Understanding and Controlling Software Costs," IEEE
Transactions on Software Engineering, October 1988).
A Lean Software Fitness Program. Keeping software from getting chubby in the middle of the project is difficult
because pressure to add more features originates from all project stakeholders. End-users
want more features because want their needs to be addressed specifically. Marketers want
more features because they perceive the market to be feature-driven; they want their
software to stack up well against the competition. Developers want more features because
each developer has areas of special interest and will be sure to do whatever work is
needed to satisfy those interests, even if doing that increases software complexity.
These stakeholders will try to work their favorite features into the
software even after the formal requirements specification activity is complete. Users
sometimes try to end-run the requirements process and coax individual developers into
implementing their favorite features. Marketers build a marketing case and insist that
their favorite features be added part way through the project. Developers implement
unrequired features on their own time or when the boss is looking the other way.
Even the smallest features pack more calories than you might think. Each
small addition can have ripple effects on the projects design, code, test cases,
documentation, customer support, training, configuration management, personnel
assignments, management communications, staff communications, planning, tracking, and
ultimately on the projects schedule, budget and quality.
Several studies have found that feature creep is the most common or one
of the most common sources of cost and schedule overruns (J. Vosburgh, et al,
"Productivity Factors and Programming Environments," Proceedings of the 7th
International Conference on Software Engineering, IEEE Computer Society, 1984; Albert
L. Lederer and Jayesh Prasad, "Nine Management Guidelines for Better Cost
Estimating," Communications of the ACM, February 1992; Capers Jones Assessment
and Control of Software Risks, Yourdon Press, 1994; The Standish Group, "Charting
the Seas of Information Technology," 1994). Feature creep is a major factor in
project cancellations; changes resulting from feature creep can even destabilize a
productby adding complexityto such a degree that it cant be finished at
Change Board. Mid-project feature additions are expensive, but
putting the software on a starvation diet by stopping changes altogether is rarely in the
projects best interest. Projects must remain flexible enough to add functionality
that end users or the marketplace declare to be absolutely essential. The question for
most projects is how to limit feature additions to those that are absolutely essential.
The typical means of limiting changes is to use a software change board,
which acts as a central clearing house for changes. It ensures that the costs and benefits
of each proposed change are considered before the change is accepted, that all important
viewpoints are considered, and that all concerned parties are notified of whether each
proposed change is accepted or rejected.
A change board typically consists of representatives from each of the
projects major concerned parties including project management, marketing,
development, quality assurance, documentation, and user support.
Multi-Version Planning. To effectively support lean software,
the change board must say "No" to new features more often than it says
"Yes." One great help in saying "No" to adding features to the current
version of the software is being able to say "Yes" to adding those features to a
future version. Consider maintaining a list of features that will be implemented in the
next version. Adding a requested feature to the list emphasizes that youre listening
to peoples concerns and that you plan to address them at the appropriate time. This
approach works especially well if you create a "multi-release plan," which maps
out a multi-year, multi-version strategy for your software. Seeing the plan helps people
understand that the feature they want is more appropriate for a later release and that it
wont be delayed indefinitely.
Short Release Cycles. Planning to deliver software often is one
key to keeping each release from bulking up. For users and customers to accept the
multi-version approach, they must have some assurance that there will in fact be a version
after the current one. If you dont think youll eat again until next week,
youll eat more than if you know your next meal is only a few hours away. If users
fear that the current version will be the last version they ever see, theyll try
hard to put all of their pet features into the current version. Witnessing a series of
short release cycles helps to build users confidence that their favorite new feature
will make it into the software eventually, just not into the current release.
User Interface Prototyping. While change boards are probably
the most common means of controlling mid-project feature bloat, prototyping is one of the
most effective. Prototyping tends to lead to smaller systems. My wife doesnt
necessarily know what I want for dinner, and the features that developers think users want
are not always the same as the features that users themselves would order from the
software menu. Conversely, without prototyping, users sometimes insist on features that
look good on paper but work poorly in the live software. User-interface prototyping can
cull those features early in the project, which makes it easier to keep both the feature
set and the budget fit and trim. One survey of projects that used prototyping found that
prototyping reduced development effort (and, by implication, software size) by 45 to 80
percent (V. Scott Gordon and James M. Bieman, "Rapid Prototyping: Lessons
Learned," IEEE Software, January 1995).
Software Miracle Diets. None
of these practices is a software miracle diet, and none of them will keep a slothful
software project from piling on the pounds. But when requirements scrubbing, change board,
multi-version planning, and user interface prototyping are combined into a comprehensive
software fitness program, the result can be fast delivery of svelte, powerful software.
Keep the fat where it belongs: at project end, use the money that your
lean software saves to treat the development team to a well-deserved banquet.