But when it has come to be a hereditary creed, and to be received passively, not actively—when the mind is no longer compelled, in the same degree as at first, to exercise its vital powers on the questions which its belief presents to it, there is a progressive tendency to forget all of the belief except the formularies, or to give it a dull and torpid assent, as if accepting it on trust dispensed with the necessity of realizing it in consciousness, or testing it by personal experience…
This work aims to help people understand how to do a better job of building complex systems. The strategy I use is to gather together in one place many things that people have already learned, but not necessarily understood as connected.
This strategy has good company. Many people over the years have worked to improve engineering and management practices. Many of those works have led to improved project performance and better systems—and every one of them I know about has had a down side. This work will be no exception.
I imagine the reader as I am writing this work, as if we are having a conversation. But in truth this is not conversation; whoever reads this cannot ask clarifying questions, and I cannot respond with better explanations where the writing is unclear. This leaves me to wonder: will the reader read and understand what I meant to say?
Everything I am writing is based on my own experience, whether it comes directly from projects I have worked on or from what I have learned from others. This raises, as for any work, questions about biases in viewpoint and correctness. I have tried to question my viewpoints by checking them with others and comparing my conclusions to their experience, but that will always be an imperfect approach to the truth. So there are two other questions: is what I present here correct? And will it apply to new situations that I do not now imagine?
There is yet a third worry in writing a work like this. Will it come to be treated as the truth, unquestioned? Will someone treat it as dogma?
A work like this one, which provides practical guides for doing complex projects, can prod people who already have some experience into new thinking about how they do their work, adding new perspectives or providing overviews that help them think about what they are already doing. It adds to what they already know, but does not serve as the only guide for how they work.
In the longer term, though, every work like this that I know about has come to be taken as a One True Approach, where decisions are justified by saying “that’s how it is written”—without the people involved actually understanding why that approach says what it says, and not thinking through how the guidance applies to the actual work they have in front of them.
There are two examples that illustrate this behavior.
NASA has an extensive set of processes and procedures, with extensive documentation. The NASA Systems Engineering Handbook [NASA16] is an accessible way to start exploring that process. The processes have evolved over several decades of experience in what what leads space flight missions to fail or succeed, and the procedural requirements are full of small details. People will do well to understand and generally follow those procedures for similar projects.
However, this has led to too many people within NASA and the associated space industry to follow these requirements blindly. A NASA project must go through a sequence of reviews and obtain corresponding approvals to continue (and get funding). I have watched projects treat those reviews pro forma: they need a requirements review, so they arrange a requirements review, but nobody actually builds a useful (or even consistent) set of requirements to be reviewed. A preliminary design review has a checklist of criteria to be met, so presentation slides are prepared for each point, but the reasons behind those criteria aren’t really addressed. And a little while later the project is canceled because it isn’t making good engineering progress.
Similarly, the Unified Modeling Language (UML) [OMG17] brought together the experience of many software and system engineering practitioners to create a common notation for diagramming to describe complex systems. The notations provided a common language teams could use to express the structure and behavior of systems, so that everyone on a project could understand what a diagram meant. A common notation allowed organizations to build tools to generate and analyze these drawings. While not everyone follows the notation standard exactly, the standard has improved the ability of many engineers to document and understand systems. I certainly use many elements of UML diagramming regularly.
The UML has had a corresponding downside. Engineers who first learned how to think about systems using UML have had trouble thinking in other ways. In particular, there are some aspects of system specification and design that are not fundamentally graphical—but some people who have grown up on UML find themselves uncomfortable working with tabular or record-structured information in databases (such as for requirements). I worked with one engineer who was using the SysML dialect of UML, which does not include all of the diagram types in the main UML language. He needed a kind of diagram in UML but not in SysML, but was shocked at the suggestion that he should just use the UML diagram he needed anyway because it “wasn’t part of SysML”.
Generalizing from these, the problem is that when something provides a general, comprehensive guide about how to do complex work, this thing can come to be treated as the only answer. People who only learn from that one source can end up with a constricted understanding of how to do the work.
And so I hope that those who read this work will not take what is written here as the only word on the subject. A guide is not a substitute for learning and thought. I hope that readers will take what I have gathered here as inspiration to think about the work they will encounter in making complex systems, drawing on their own experience and the experience of other around them as well as what has been written. I hope that the points in this book help people keep in mind why something is being done, so that they can address the spirit of the need in addition to the rules of any particular procedure or methodology.
Finally, this last point has caused some reviewers to raise a concern about this kind of caution. By insisting that this book doesn’t have the complete answers to anything, and that people will have to think for themselves to do good systems work, it leaves the door open for anyone to justify to themselves any choice they care to make.
This is a valid concern. I have worked with lots of people who have made bad management and engineering decisions, and who were convinced they were right. In truth everyone makes poor decisions, and everyone has limited perspective. Every single project and every single person involved in building systems will face difficult decisions and will make some of them poorly.
In the end, I have decided that this is not something one can address with a book. I do not know who will read this work in future; I cannot know or address the specific problems they will have. I cannot have a conversation with each of you to try to sort through the actual problems and decisions you encounter. All I can do is provide you with one perspective, and hope that you will add it to your own in useful ways.