Software Isn't Soft
One more 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
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
No matter how
What's interesting about this example is that I can ask a whole hat full 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 should not 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 the known present need against the possible future need and determining how "soft" or "hard" to make the "ware."