An Analogy for Software Development

Sometimes, I have to explain software development to people who are not software developers. Over the years, I have come up with an analogy that explains what software development is like and its processes. I have successfully used it to explain software development to a 9-year-old kid, including advanced concepts like cybersecurity and so forth. I figure others might benefit from it, so here it is:

Imagine that you live in a world without computers. You are the owner of a custom car factory, where people can write down on pieces of paper any car they want in the world, and your factory will build it for them. However, these cars are not built by humans. Instead, they are built by special robots that can read and follow instructions (but not think for themselves).

The way that the robots know how to build the car is that there is a special book of instructions that describes how to build each piece and how to put together these pieces into any car that anybody could want. This book is huge—100,000 pages of exact instructions for the exact steps that the robots need to do, taking into account any situation the robots could potentially find themselves in while building the car. (For example, what if one of the robots breaks while they are building a piece? What if the factory runs out of materials for the piece they are building? What if a customer asks to put together two pieces that no customer has ever asked for before, and the instructions for how to do that aren’t in the book? And so on—every possible circumstance that you can imagine. That’s why the book is so long.)

It is obviously impossible for one person to create the instructions in a book with 100,000 pages. So this book is written by 1000 people, all working together on the same book. Some people write instructions for how to build car engines. Other people write instructions for how to build car doors. And so on, for every piece of the car and every way of combining them. All the instructions in the book have to all “agree” with each other—for example, if I build a door, it has to be able to attach to the body of the car. If I build tires, they have to fit the wheels. So all the authors of this book are constantly working together to make sure that all the instructions in the book work correctly together.

As new types of car parts come out, new instructions have to be written. As the authors of this book discover new situations the robots could find themselves in (“Oh, we didn’t realize that when it rains, some of the pieces can rust!”) they have to update the instructions in the book. In other words, not only does the book have to be written once, it is actually constantly changing. In fact, there is almost always more work needed to keep the book up to date than there is work being done to write new instructions.

Now, if this sounds like an impossible problem to solve, don’t worry. No single human being could possibly comprehend the entirety of the book. So if you feel overwhelmed by the problem, that’s normal! Every human being in the world feels that way about the problem. It’s 100,000 pages of constantly-changing instructions. So how do we do it? We set rules about how the book will be written. For example, we say “doors will always attach to car bodies the same way.” Like, the doors will always have the same type of hooks that connect them to the body, and the bodies will always have the same place for those hooks to fit in. That way, no matter what door you build or what body you build, they always fit together. Now we don’t have to think about that problem any more. We set lots of rules like this so that each person writing the book can safely work on their part of the book without worrying they’re going to break the whole car just by changing one instruction about the wheels or the engine. As long as each author follows the rules, they can change anything in the book and the whole car will keep working. This limits what types of cars we can possibly build, but it makes solving the problem possible, where otherwise it is impossible.

These authors, the people writing and maintaining this book, are software developers. The problems they encounter are nearly identical to the problems that software developers and development teams encounter. For example, how do you know that you wrote instructions that actually work? What happens when somebody new starts working on the book, how do they learn the rules? What happens when there are so many rules that the authors can’t remember all of them? How do the authors learn about new cars and new car parts that customers want to build? You can explain essentially all the processes, problems, and principles of software development to anybody, using this analogy.

I hope it helps!

-Max