Software isn’t soft

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:

• Is ten an upper limit on the number of reports?
• Will the future reports be similar to the initial five reports?
• Will all of the reports always be printed?
• Will they always be printed in the same order?
• To what extent will the user be able to customize the reports?
• Will users be allowed to define their own reports?
• Will the reports be customizable and definable on the fly?
• Will the reports be translated to other languages?

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:

• Defining more than ten reports
• Defining a new report that is different from the initial set of reports
• Printing a subset of the reports
• Printing the reports in a user-defined order
• Allowing the user to customize reports
• Allowing the user to define an entire custom report
• Translating the reports to another language that uses a Latin alphabet
• Translating the reports to another language that uses a non-Latin alphabet or that reads right to left

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.”