One kind of “fool’s gold” is the belief that software is soft. Hardware is “hard” because it is difficult to change. Software was originally called “soft” because it was easy to change.
For very small programs at the dawn of computer programming, this might have been true. As software systems have become more complex, however, this notion that software is easy to change has become one of the most pernicious ideas in software development.
Several studies have found that changing requirements—attempts to take advantage of software’s supposed softness—are the most common, or one of the most common sources of cost and schedule overruns. They are also a major factor in project cancellations; in some cases, changes resulting from creeping requirements can destabilize a product to such a degree that it can’t be finished at all.
A simple example illustrates why software isn’t as soft as people think. Suppose that you are asked to design a system that will initially print a set of five reports and eventually print a set of 10 reports. You have several kinds of flexibility—softness—that you will need to be concerned about:
No matter how carefully the software is designed, there will always be a point at which the software won’t be soft. In the case of the reports, any of the following areas could turn out to be “hard”, for example:
What’s interesting about this example is that I can ask a whole series of questions about the “softness” of these reports without knowing anything whatsoever about the specific reports or even about the system within which the reports will be printed. Simply knowing that there are “some reports” raises many general questions about the different degrees of softness.
It’s tempting to say that software developers should always design the software to be as flexible as possible, but flexibility is an almost infinitely variable entity, and it comes at a price. If the user really wants a standard set of five preformatted reports, always printed as a set, and always printed in the same order in the same language, the software developer would not need to create an elaborate utility that allows the user to generate highly customized reports. That could easily cost the customer 100 to 1,000 times as much as providing the basic functionality the user really needs. The user (or client or manager) has a responsibility to help software developers define the specific flexibility needed.
Flexibility costs money now. Limiting flexibility saves money now, but typically costs disproportionately more money later. The difficult engineering judgment is weighing up the known present need against the possible future need and determining how “soft” or “hard” to make the “ware.”