Tom DeMarco made software analysis and development inherently safer in 1978 when he published his classic, Structured Analysis and System Specification.
Even back then, Tom saw how unsafe it was to:
- shoot once for perfection
- write giant specifications
- define behavior via ambiguous language
- let software maintenance costs soar
- produce poorly designed code
- perform insufficient testing
Let’s examine some of Tom’s key insights.
Instead of shooting for perfection, Tom acknowledged our fundamental need to iterate:
“The human mind is an iterative processor. It never does anything exactly right the first time. It is particularly good at taking an imperfect implementation of a given task, and making significant improvements to it. This it can do over and over again, coming up with better results each time.”
Rather than writing giant specifications, Tom suggested producing mini-specifications:
“We have to stop writing Victorian novel specifications, enormous documents that can only be read from start to finish. Instead, we have to learn to develop dozens or even hundreds of mini-specifications. And we have to organize them in such a way that the pieces can be dealt with selectively.”
Tom would be quite at home with Agile’s iterative approach to user stories and the mini-specifications we write as scenarios.
Rather than using ambiguous language to define system behavior, Tom showed how a variety of diagrams, including Context Diagrams, could help clarify essential functionality, like important system inputs and outputs.
Rather than living with high maintenance costs, Tom said "Maximize the ease of modifying the system."
He wrote, “Because there is so much to be gained by reducing the cost of maintenance, it makes good sense to dedicate extra development effort if that will help.
In particular, if an additional 10 percent expenditure on design and coding could reduce maintenance costs by 10 perfect, the trade-off would be overwhelmingly favorable.”
Rather than letting poorly designed code yield expensive software maintenance, Tom suggested using Larry Constantine’s design characteristics, defined below.
Constantine’s Design Characteristics for Low-Cost Maintenance
Larry Constantine analyzed maintenance costs and software designs on numerous systems to formulate his design characteristics for low-cost software maintenance.
Here they are, together with partial explanations (not the original full paragraphs) by Tom DeMarco:
- Small module size: The smaller the modules, the more likely it is that an impact of a given change (or fix) can be effectively isolated…
- Modular independence: The less the inside of one module depends upon anything that is inside another module, the easier it will be to maintain…
- Black-box characteristic: The black-box characteristic applies to any system, program, or module that can be viewed in terms of inputs and outputs alone, without worrying about the details of how it processes them…
- Conceptual modeling: The structure of any system takes its shape from something. That something is the model for the system…
- Isolation of detail: There ought to be reasonable separation between those parts of the system which reflect its underlying philosophy, and those parts which reflect mere details…
These design characteristics still hold true today.
Instead of performing insufficient testing, Tom suggested making all code easily testable and performing good acceptance testing.
He clearly defined acceptance tests as normal path tests, exception path tests, transient state tests, performance tests and special tests.
In short, Tom’s classic book helps us learn that it is safer to:
- iterate rather than shoot once for perfection
- break large specifications into mini-specifications
- use diagrams when words are unclear or ambiguous
- “maximize the ease of modifying the system”
- use Constantine’s low-maintenance-cost design characteristics
- make code testable and perform a variety of acceptance tests
Tom made the software industry safer for practitioners in the 1970s and his wisdom is still relevant today.
