Inside Risks: Learning from Experience

Despite a half-century of practice, a distressingly large portion of today’s software is over budget, behind schedule, bloated, and buggy. As you know, all four factors generate risks, and bugs can be life-critical. Our reach continues to exceed our grasp. While hardware has grown following Moore’s Law, software seems to be stuck with Gresham’s Law. Most providers studiously avoid taking any responsibility for the software they produce.

These observations are not new. They were eloquently presented at the famous 1968 NATO conference for which the term "software engineering" was coined.¹ But many of today’s programmers and managers were not even born in 1968, and most of them probably got their training after the conference proceedings went out of print.

For those who care about software, wonder why it’s in such bad shape, and want to do something about it, I prescribe the study of both the current literature and the classics. It is not enough to learn from your own experience; you should learn from the experiences of others: "Those who cannot remember the past are condemned to repeat it."

I have long recommended the book The Mythical Man-Month (Frederick P. Brooks, Jr., Addison-Wesley, 1995). It is a product of both bitter experience ("It is a very humbling experience to make a multimillion-dollar mistake") and careful reflection on that experience. It distills much of what was learned about management in the first quarter-century of software development. This book has stayed continuously in print since 1975, with a new edition in 1995. It is still remarkably relevant to managing software development.

Now there is another book I would put beside it as a useful source of time-tested advice. Software Fundamentals: Collected Papers by David L. Parnas (M. Hoffman and D.M. Weiss, Eds., Addison-Wesley, 2001) is more technical and less management-oriented, but equally thought-provoking. In one volume, it covers many risks-oriented topics. Parnas has been writing seminal and provocative articles about software and its development for more than 30 years, based on original research, observation, and diligent efforts to put theory into practice, often in risky systems such as avionics and nuclear reactor control.

Software Fundamentals collects 33 of Parnas’s articles, selected for their enduring messages. It includes such classics as "On the Criteria to Be Used in Decomposing Systems into Modules"; "On the Design and Development of Program Families"; "Designing Software for Ease of Extension and Contraction"; "A Rational Design Process: How and Why to Fake It"; and "Software Engineering: An Unconsummated Marriage." It also has some lesser-known gems, such as "Active Design Reviews: Principles and Practices" and "Software Aging." Even if you remember these articles, it is worth refreshing your memory.

The articles were written to stand alone. Each has a new introduction, discussing its historical and modern relevance. Thus, readers can browse the papers in just about any order, choosing those that catch their interest. However, this is a book where browsing can easily turn to serious study; the editors’ arrangement provides an orderly sequence for reading.

Whether browsing or studying this book, you’ll be struck by how much of today’s "conventional wisdom" about software was introduced (or championed very early) by Parnas. Equally surprising is the number of his good ideas that still have not made their way into current practice. Anyone who cares about software and risks should ask, Why?

Parnas is never dull. You won’t agree with everything he says, and he’d probably be disappointed if you did. Pick something he says with which you disagree (preferably something you think is "obviously wrong"), and try to construct a convincing theoretical or practical counterargument. You’ll probably find it more difficult than you expect, and you’ll almost surely learn something worthwhile when you discover the source of your disagreement. Then, pick one of Parnas’s good ideas that isn’t being used where you work, and try to figure out why it isn’t. That could inspire you to write a new column.

Back to Top

Back to Top