Works of Christopher Alexander. Christopher Alexander was an architect, who advocated for a human-centered design in buildings and cities. His approaches to designing and building building and towns influenced more general systems development practices, including the idea of pattern languages and agile development.

There are three Alexander books that have influenced my thinking. In these works, he addresses questions of how structure and pattern apply to complex systems—in particular, how the relationships between things is a necessary part of understanding how a system works. (The system organization in Chapter 12 is informed by his ideas.)

• A City is not a Tree [Alexander15]. This is an early essay on how cities cannot be viewed as being spatially organized as a tree—that is, that one region of a city cannot be viewed only in terms of the larger region of which it is a part, but rather that city regions have a complex web of relationships. He argues that this more complex web must be taken into account when designing or analyzing a city. For example, a block containing an industrial site must be considered not just as part of an industrial zone, but also in terms of the transportation network that brings workers to and from the block, the network that carries resources and finished products, or its relation to atmospheric currents and sight lines.

• The Nature of Order [Alexander02]. This is an ambitious, multivolume work that wrestles with basic ideas of structure, order, and patterns. He proposes a set of patterns that give a built environment “life”, by which he means a kind of human accessibility that leads to promoting human growth and well-being. He argues that process and patterns that lead to these qualities can be understood empirically, and that they hold across cultures and times.

• A Pattern Language [Alexander77]. This is a collection of more than two hundred patterns that work together to form a basis for a humanist built environment. This book led to the use of pattern languages in software engineering.

Engineering a Safer World. Nancy Leveson and colleagues have developed a set of methodologies for designing and understanding safe and secure systems. The book Engineering a safer world [Leveson11] makes the case that safety and security must be treated using a systems approach, and then presents a causality model (STAMP), a safety and security design analysis technique (STPA), and an incident analysis technique (CAST).

This work affected how I think about designing safe and secure systems. Before encountering this work, I had cobbled together a set of techniques to support designing secure systems, based on collaboration with a number of people on a series of DARPA projects. I used basic fault tolerance techniques. I worked with other safety standards, notably ISO 26262 [ISO26262], found that the methods in those standards were missing many of the hazards I was finding. Leveson’s book provided me with a way to articulate the overall systems aspect of safety and security work, as well as providing better tools for the job.

Scaling People. Claire Hughes Johnson has translated her experience building teams and companies into a book that does for team structure and operations what I am trying to achieve for systems building. Her book, Scaling People [Johnson22], sets out basic models for how to build an organization and grow it. The book begins with a few key behavioral principles that apply to engineering work just as well as to business operations. The book proceeds to develop a model for operations, organized as four “core frameworks”.

Two specific ideas from the first core framework resonate with the engineering work I set out in this book. First, she stresses the importance of writing down founding documents: a record of what an enterprise is for, its goals, philosophy, mission, and principles. Second, she makes the case for defining an “operating system” for the organization. It documents “a set of norms and actions that are shared with everyone in the company”; it defines the basic structures and processes that the company follows. The book is notable for not just presenting these ideas, but making the case for why each idea is important based on her experience and on the experience of others in the industry. It also provides examples of the documents that companies have actually used—so that it’s clear how to put the ideas into practice.

This book has helped me articulate ideas about team organization, communication, and the value of documenting processes.

Management by Peter Drucker. In the mid-1990s I had the chance to take some courses and workshops on “how to be a manager”. One of those courses referenced Peter Drucker’s book Management: Tasks, Responsibilities, Practices [Drucker93]. I ended up reading the book cover to cover, and it gave me the framework to think about businesses that I had been looking for. I had not re-read it for many years when I started working on this book, but when I did begin to re-read it, I found that many ideas that I used nearly every day, and that I had no longer a conscious memory of where they came from, in fact came from that book.

A book on managing organizations is a necessary complement to information about systems work. A system-building project does not exist in a vacuum. It is part of one or more organizations. Those organizations provide capital and other resources to perform the project. The organization is a stakeholder in the project; the organization has objectives and imposes constraints on what the project does. People in the organization use its objectives and policies to decide whether to take on a project or not.

Knowing how the organization works is therefore important to a project. A clear understanding of how the organization works helps people on the project make decisions that support the organization and that, in turn, lead to the organization continuing to support the project.

Many of the key ideas about how an organization operates in the large also apply to how a project operates. A business or other organization needs a defined purpose that is shared to the whole team. People in the organization need clear and performable objectives. Measurability of objectives or plans matters for a project just as it does to a project. Organizations have structure, as does a project team. Both an organization and its project are responsible for understanding and managing their societal effects.

Drucker is notable for refusing to simplify complex aspects of organizations and work. For example, in discussing what “working” is, he identifies six dimensions that must be considered (physiological, psychological, social and community bond, providing economic needs, cost, power relationships, and distribution [Drucker93, Chapter 16]). He insists that all these dimensions must be considered, and that they interact with each other.

Management is particularly notable for clarity about the functions of an organization, and how its management performs those functions. He says that the purpose of management is to serve to make the organization function; it is not an end in itself, and “what people mean by bureaucracy, and rightly condemn, is a management that has come to misconceive itself as an end and the institution as a means.” [Drucker93, Chapter 4] He also is clear that an organization—and by extensions, the projects that are performed under its aegis—must be considered in the context of the society in which they exist.

In this book, I focus on the system-building project. Because a project is both a part of an organization as well as an organization in microcosm, the more expansive view that Drucker provides is helpful in understanding the why of projects.

Estimation. I haven’t had good experiences with estimation, mainly because I had little training and because only one project I’ve worked on actually wanted to know real estimates; that one was wanting estimates before good estimates were really possible

At the same time, I have always known that the projects needed reasonable estimates of how much effort or resource some task or feature would take.

I asked my brother for advice; he has managed successful complex projects that included realistically estimating how much time and how many people would be needed. He reported that after his company started taking a more rigorous approach to estimation, they completed more projects, did so mostly within budget, and (the surprise) improved team satisfaction and retention. His company arranged for formal training for their staff to make this happen. The training used the book Software Estimation: Demystifying the Black Art [McConnell09].

I have found that book to be a clear and pragmatic treatment of estimation. It covers—in broad terms—three ideas: what estimation is, how to do it, and how to use it. The definitions of what estimation is, and how it differs from targets (what people want) and commitments (the effort or schedule that has been agreed to) is helpful. The explanations of different estimating techniques and when to use them are clear. I found the material about how to use estimates, and in particular about how to communicate about estimates, refreshing.