TLDR; It still has moments of well worth reading but it also has sections where you hope no-one follows the instructions.
I haven’t read this book since University but I vaguely remembered it as one of the books that taught me system modelling, a skill that I still rely on to this day.
A Caution
Early on in the book we learn that ‘analysis is not very satisfying’ ’largely because it is so indefinite’ and ’there are so many compromises to be made that no one is ever completely happy with the result’. And this, I think is why modern software development values a running and deployed system; something definite that we can use to learn if we are happy with the results and direction that we are taking. Constantly talking, conceptualising and building an ever larger model of the potential system without seeing it and having the ability to check if you are conceptualising the right thing does satisfy very few people.
Unfortunately some projects do carry on this tradition with large detailed backlogs, but they tend to avoid the diagrams and data dictionaries that Demarco describes in this book.
A good start
On page 8 Demarco provides something of value when he discusses estimates - we only get 3 paragraphs on page 8 and Demarco waits until the final chapter (27) before writing 7 pages that still stand up well today and I’d love to be able to link to an excerpted reprint but you might have to read the book to gain access to them.
“Nobody is an expert estimator. You can’t even take a course in estimating because nobody is willing to set himself up as enough of an authority on the subject to teach it.”
“We don’t build our estimating skills, because we don’t collect any data about our past results.”
“None of this matters as much as it ought to anyway, since most things we call ’estimates’ in computer system projects are not estimates at all… nothing more than Wishful Thinking”
Demarco goes in to more detail later but reminds us that he provides estimating heuristics.
“A heuristic is a cheap trick that often works well but makes no guarantee. It is not an algorithm, a process that leads to a guaranteed result.”
Demarco, on page 9 cautions us that “the analyst should be guided by a rule which seems to apply almost universally” The overriding concern of analysis is not to achieve success, but to avoid failure. Analysis is essentially a defensive business."
Regarding the body of the book
Demarco describes analysis in the book as Structured Systems Analysis but we can apply the general concept of ‘analysis’ to any of the Software Development activities - design, testing, programming, management, etc. And analysis requires us to model the system and think through the model to select an ‘optimal target’ and document it ‘in such a manner that subsequent implementation can be evaluated to see whether or not the target has been attained’.
Throughout the early sections of the book we learn that analysis phases can go horribly wrong and can cause problems to fail and that large documents can be redundant, wordy, “tedious to read and unbearable to write”. And yet at the time there didn’t seem to be much alternative in Software Development, so looking back on the book today we have to skip a lot of the text.
I think it is still worth learning the concepts of Data Flow Diagrams, Data Dictionary, Decision Tables and Decision Trees. I’m tempted to say avoid Structured English, but Structured English has a mapping to Modern Software Development in the form of Domain Specific Languages and there might be some value in reading about it.
But when we do read about them we have to treat them with less formality than Structured Analysis required:
- DFDs can be useful graphical representations that help you think through flows in a system. I still use them.
- Data Dictionaries can be useful to name and represent concepts, I’ve used the concept to help me design and generate test data.
- Decision Tables and Decision Trees I use far less often but they can provide concise thinking tools
DFDs teach you concepts of graphical modelling, paritioning diagrams, logical modeling, multiple levels of abstraction, simple representations. You might even find yourself using GraphViz (see also recommended tools)to create diagrams that are easy to version control and create.
At this point I’ve skipped about 19 chapters. And then the book starts to have more relevance to Modern Software Development.
On Modelling a System
Chapter 20 describes building a logical model of a system which is a skill I think all testers need to develop. This is a small chapter and isn’t worth buying the book for - you’ll probably be better of with “Domain Driven Design” but the chapter here is very small and describes domains and partitioning of models into domains and different context diagrams.
“The analyst is boss. Instead of being guided by the users’s political and procedural view, the analyst partitions according to his own standard: minimization of interfaces”
I think “minimization of interfaces” is a good rule for creating models that are easy to grok and help focus your attention on specific domains, and help you when you model the system in code to create abstraction layers for automated execution.
I think a slightly truncated and amended version of the paragraph provides splendid guidance to testers when modelling a system, assuming that you identify with the analyst in the sentence.
“The analyst is boss. Instead of being guided by [someone else’]s political and procedural view, the analyst partitions according to his own standard.”
There. I like that. I do that when I model a system to help me test.
Chapter 20 also provides guidance that we can use when again modelling the system in code to create abstraction layers for automated execution.
- Partition to minimize interfaces
- make sure your objects have small interfaces, this helps limit there responsibility
- Pay attention to names
- the advice given here matches advice you’ll find in books such as Clean Code
- Respect conceptual counting limits
- keep number of classes, methods, packages etc. small (at each level of a hierarchy or partition)
- Be prepared to start over
- refactor and rework as you learn more and actually use your abstractions in earnest.
We have to skip a few chapters on waterfall phases and documents and change control processes… but eventually we find some useful information on coupling and cohesion which Demarco has adapted from Glenford Myers book “Reliable Software Through Composite Design”. Again giving us a heuristic around naming to identify when a something is of unacceptable cohesion i.e if the name “is wichy-washy or involves multiple verbs and objects”. The chapter then provides more examples of logically modelling and partitioning a model into different domains and abstractions.
On Acceptance Testing
In some ways Chapter 26 “Acceptance Testing” acts as a fore runner for ATDD “acceptance testing is binary: it proves either that the project was a success and the system met its target, or that it did not.”. If the Acceptance Testing was automated to meet the acceptance criteria then failure of the Acceptance Tests does mean that the system did not meet its target. Indeed Demarco goes further and says:
“The Cardinal Rule of Acceptance Testing : Acceptance tests are derived from the Target Document and from the Target Document alone.”
And here Demarco clearly mean Target Document to mean Acceptance Criteria.
Thereby ruling out Exploratory Testing except…
Demarco lists the Acceptance Testing as:
- normal path tests
- exception path tests
- transient state tests
- performance tests
- special tests
“Special Tests”? What are they then Tom?
“It would be naive to think that any system, no matter how complex, could be tested completely by the derived test sets as I have explained them. Clearly some systems require additional tests to deal with their very particular natures.”
“some”? Surely, Tom, you mean All, or if you wanted to play it safe “Most”?
“For such special tests I suggest this protocol: Since they cannot be derived from the Structured Specification, they must be placed explicitly in the Structured Specification before it is considered complete. This will maintain the standard that all the criteria for acceptance are contained in the Structured Specification”
OK. So what I heard Tom say was:
- do Exploratory Testing on the system
- that way you’ll learn stuff about the system because the Acceptance Criteria are not complete
- create notes to communicate what you tested and what you learned
- we’ll add that information into the stories to make them complete
On the “Heuristics for Estimating”
And then in Chapter 27 Tom provides the “Heuristics for Estimating” that still stands up today and I wish I could point to it in a pdf in full for you to read.
- “Estimating is different from regurgitating”
- very often our ’estimate’ is a regurgitation of a ‘right answer’ e.g. “You’ve got a week to do it, how long will it take?” A week? Right Answer - regurgitation
- “Estimating is different from negotiating” - “When you come up with your best estimate of an unknown, it makes no sense at all to let someone, namely your boss, make a counter offer.”
- “Estimations are not subject to bargaining” - “It is well to cultivate an air of stunned disbelief to greet any attempt at bargaining. At the very least, you are now obliged to tell whoever makes the counter offer that the estimate is now his.”
- “estimating is different from dividing a fixed duration into component parts”
Tom Demarco provides a few more rules, and I hope you have the opportunity to read this chapter for yourself in the future.
Conclusions
I think there are some important concepts in this book - you will find similar concepts in books such as “Domain Drive Design”, “Growing Object-Oriented Software”, “Implementation Patterns”, “Clean Code” and many others.
A lot of this I use for building models to help me explore the system, but it has clearly also influenced the way I model the system in code to create abstraction code for automated execution.
I’m glad I re-read the book, I’m more glad that I read it early in my career and it provided - along with many of the design books from the 70’s and 80’s a foundation for logical modelling and abstraction that I still use today. I caution against taking some of its absolute pronouncements as gospel, when they require a more flexible interpretation for the Modern World of Software Development.
