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