Developing software means to start a project, to deliver a first working version and then to maintain that software and deliver successive version.
I like the house building metaphor. First a house is built and delivered. Then that building requires maintenance work. A difference between software and buildings is that a newly built house do not requires maintenance intervention for the first several years, while software requires immediately maintenance interventions, because usually not every required feature has been fully and correctly implemented in the first version, the first version has many defects that are reported only after the first version is released, and several new or changed requirements emerge only using the actual delivered system.
Another consequence of what said before is that software maintenance is proportionately much more costly that building maintenance. Actually, building maintenance is usually a small fraction of the cost of the building, while software maintenance over a span of ten years is typically more costly than the cost of the first version.
There are techniques to make a software system more maintainable at the expense of a longer initial development time. These techniques are rarely used though, for the following reasons:
- Many new projects are abandoned before the first release or little time after it. If the first version is more costly than necessary, these projects lose more money.
- For many new software products the earlier is delivered the first version, the more profitable is the project. A small delay may even turn a success into a failure. Therefore, the shorter is the time to develop the first version, the better.
Some other times, though, a more maintainable system is required. In particular, this is required when the product success is probable, a long lifetime for it is expected, and there is no hurry in delivering an early version. In such cases it is advisable to apply the quality-improving techniques described later.
Every new project and every maintenance intervention should start with a requirements document. Sometimes requirements are only oral, but this always an error, because a written requirements document takes little time to write and is of great usefulness.
The complexity of the requirements document depends on the complexity of the intervention.
The initial project should have a big requirements document, describing the whole required system. But also every maintenance intervention should have a (small) requirements document.
The simplest useful requirements document is a text file having the following structure:
- Title: A line describing the intervention.
- Present situation: A description of the undesirable features of the present system.
- Required situation: A description of the desirable features of the required system.
Therefore a useful requirements document may be as small as a three-lines text file.