Best Practices
IEEE Software, Vol. 13, No. 1, January 1996
Who Cares About Software Construction?
Software practitioners are subjected to a barrage of advice about
effective development practices. The search for effective
practices--programmers' gold--can be almost as treacherous as the search for
the precious yellow metal itself. Some mediocre practices are overhyped and
don't pan out; many valuable practices are buried under other practices'
hype. This column aims to separate the gold from the ore by providing a
practitioner's appraisal of past and present development practices. Future
columns will take up practitioner-oriented topics ranging from "Whatever
happened to information hiding?" to "The estimation story--Defending
unpopular estimates."
-- Steve McConnell
I am going to admit something that people rarely admit in refereed software
journals these days:
I like coding.
I admit it, and I'm not embarrassed. I don't hang my head when I say I
enjoy low-level design, unit testing, debugging, and optimization. I do not
find these low-level construction activities even a little demeaning. I
often find them invigorating. Software construction is an important activity
that deserves more respect than it has received lately.
At one time, software development and coding were thought to be one and the
same. But, as distinct activities in the software-development life-cycle
have been identified, the best minds in our field have spent their time
analyzing and debating methods of architecture, project management,
requirements analysis, design, and quality assurance. The rush to study
these newer areas has left code construction as the neglected step-child of
software development.
Construction has also been neglected by researchers and writers because of
the mistaken idea that, compared to other software development activities,
construction is a relatively mechanical process and presents little
opportunity for improvement. Nothing could be further from the truth.
Construction is not at all mechanical. Sometimes a formal architecture
addresses only the top level of system decomposition, and design work is
intentionally left for construction. Other times a program's design is
supposed to be detailed enough to provide for fairly mechanical coding, but
there are always gaps and the coder usually designs part of the program,
officially or otherwise.
The reduction in attention to code construction has been exacerbated by the
treatment of coding as the dirtiest grunt work of the software-development
world. An entry-level programmer in a large organization is typically
assigned to code routines that have been specified and designed by someone
higher up on the corporate ladder. After a few years, the programmer is
promoted to architecture, requirements analysis, or project management and a
few years after that may proclaim with pride that it has been years since he
or she has written any code.
CENTRAL ROLE. The irony of the shift in focus away from construction
is that construction is the only software development activity that's
guaranteed to be done. Right or wrong, it's possible to assume requirements
rather than analyze them. Architecture can be shortchanged rather than
designed. System testing can be abbreviated or skipped rather than carefully
planned and executed. But no matter how rushed or poorly planned the project
is, construction cannot be dropped. If there's going to be a program, there
has to be construction.
Because construction is the only activity that must be done, code is often
the only accurate description of the software available, which makes it
imperative that the source code be of the highest possible quality.
Consistent application of detailed source-code techniques makes the
difference between a Rube Goldberg contraption and a polished, correct, and
informative program. Such detailed techniques must be applied as the code is
initially constructed because it's virtually impossible to go back later and
retrofit the thousands of picky details that spell the difference between a
maintainable program and a failure.
Even when a program is developed using effective practices, construction
typically makes up about 80 percent of the effort on small projects and 50
percent on medium projects. Construction accounts for about 75 percent of
the errors on small projects and 50 to 75 percent on medium and large
projects. (This data is approximate for detailed design, coding, unit
testing, and debugging. See, for example, Programming Productivity
by Capers Jones, McGraw-Hill, 1986.) Any activity that accounts for 50 to 75
percent of errors presents a clear opportunity for improvement.
Some commentators have suggested that although construction errors account
for a high percentage of total errors, they tend to be less expensive to fix
than the errors caused by analysis and design. The implication is that they
are therefore less important. The claim that construction errors cost less
to fix is true, but it is misleading because the cost of not fixing them can
be incredibly expensive. Gerald Weinberg reported ten years ago that the
three most expensive programming errors of all time each cost hundreds of
millions of dollars and that each was a one-line, coding-level mistake
("Kill that Code!" Infosystems, Aug. 1983). A perusal of any recent
"Risks to the Public" section of Software Engineering Notes shows
that little has changed since Weinberg made his report. Errors in those
single lines might be less expensive to fix than errors in analysis or
design, but that obviously does not imply that detecting and correcting them
should be a low priority.
OPPORTUNITY KNOCKS.What does all this have to do with best
practices?
Construction presents an unusually good opportunity to disseminate
information about best practices in software engineering. Millions of
programmers are already doing construction and can do it better. People
without formal training in computer programming have taught themselves to
program in Pascal, Basic, C, and C++. Learning about better software
construction allows these people to build on what they already know and
gives them a foot in the door to other powerful development practices.
Moreover, the number of self-taught programmers has been increasing since
the beginning of the PC revolution. The more people who do end-user
programming, the more risk there will be of expensive, coding-level
mistakes, and the more opportunity there will be to improve the average
level of software quality by focusing on improved construction practices.
In 1990, the Computer Science and Technology Board stated that the biggest
gains in software-development quality and productivity will come from
codifying, unifying and distributing existing knowledge about effective
software-development practices ("Scaling Up: A Research Agenda for Software
Engineering," Communications of the ACM, March 1990). The board
concluded that software-engineering handbooks should play a key role in
disseminating that knowledge.
In amorphous areas of software engineering such as requirements analysis
and design, there are still vigorous debates about which practices work
best. Those debates are not informed by much research. But we as a
profession have been doing software construction as long as we have been
developing software, and a mountain of research about construction has
accumulated over the years. It seems possible to codify the knowledge of
what makes for effective construction. In 1993, I took a step toward that
end by writing Code Complete, a practitioner-oriented handbook of
construction practices (Microsoft Press, 1993). But much more work still
needs to be done to identify, validate, and document effective construction
practices.
RETRAINING GURUS. It is clear from what I have seen on live projects
that young, hot-shot PC developers are making the same mistakes that their
elders made and learned to avoid 10 or 20 years ago. It is also clear from
much of what has been written that the gray-haired software-engineering
experts could learn some things from the young hot-shots (after all, there
are reasons why they are hot-shots).
School districts put administrators back into the classrooms occasionally,
and service companies put top executives back on customer-service duty. I
have a dream in which prominent software-engineering experts sign up for
construction roles on projects at modern companies like Microsoft, Borland,
and WordPerfect. An unbelievable amount has changed in the way that
production software is developed during the last 10 years, and a lot of
those differences have to be experienced on a live project to be
appreciated. Maybe this dream can never be realized because it calls for too
much individual financial sacrifice. Maybe it would seem like too much of a
step backward for a software-engineering guru to take a construction job.
But the industrywide benefit would be amazing. The insights that some of the
wisest and brightest people in our field would gain from being back on the
front lines of construction for awhile could invigorate the whole industry.
Journals such as this one can help too. Some professional journals still
publish code listings that have such poor layout, variable names, and
commenting that they are virtually impossible to read. The code listings
contain fundamental programming blunders such as using numeric literals
rather than named constants. If these code listings were created in a
production environment, the developer who wrote the code would be scheduled
for remedial training; companies whose code will be read by only a few dozen
developers hold their code to higher standards. Professional journals whose
code will be read by thousands should take a leadership role in publishing
examples of good construction.
Researchers, consultants, and writers who dismiss construction as a trivial
activity need to realize that construction, by definition, occupies the
central role in software development. Analysis and design are done before
construction so that construction can be done effectively. System testing is
done after construction to verify that construction has been done
effectively. Construction is at the center of the software-development
process. It is where the rubber meets the road, and that makes it a uniquely
productive area in which to focus our attentions.
Construction is important and will remain so for the foreseeable future.
The difference between good and bad construction can mean the difference
between project success and failure. The difference between recognizing the
key role that construction plays in software development and ignoring it can
mean the difference between moving the industry forward and repeating the
same old mistakes yet another time.
Editor: Steve McConnell, Construx Software, 11820 Northup
Way
#E200, Bellevue, WA 98005.
E-mail: steve.mcconnell@construx.com
- WWW:
http://www.construx.com/stevemcc/
