A software engineering analogy nobody asked for
Tags: programming, devops, design, webdev
Published: 2022-04-03 19:16:19

---
title: A software engineering analogy nobody asked for
published: true
description: 
tags: programming, devops, design, webdev
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p5d1edol11rx4xqzki78.png
---

## Seeking analogies

Most of us have heard many analogies comparing software engineering to other engineering practices in the physical world, such as civil engineering or car manufacturing. While seeking metaphors like these is absolutely normal due to the inherent abstract (an intangible) nature of building software, many fail to make a genuine and equivalent comparison.

Let me explain.

Comparing building software to make cars is very tempting since there seem to be some similarities, to the point that we have even spun up _software factories_ in the past. These so-called factories were based on the principles of Lean Manufacturing and the hyper-efficient and highly-automated assembly lines. There is a problem though: we don't make cars. A Toyota Prius has nothing in common with Elastic Search.

## Automation in car manufacturing

Why is it so tempting? Let me put it this way. In manufacturing, there are two clear and well-separated processes:

- **Design Phase**: You design that new car model that all your customers dream about. You capture market needs and then put your creativity together to develop a model that can be handed over to engineers to build and deliver.

- **Construction Phase**: You build that one car model that has been designed, typically through a highly-automated and hyper-efficient assembly line.

Have you noticed something already? That's right. In the car manufacturing industry, you **automate** the construction phase but never the design phase. I may be wrong, but I don't think that designing new car models can be automated in the same way they are produced. Don't mistake using software to **assist** the design phase (e.g., CAD) with software to **automate** the generation of new designs. 

## Automation in software

For building software, these two types of phases also make sense. But not in the way many people think. 

- **Design Phase (or Inner Loop)**: You design that new piece of software that your customers (think they) want. However, the tricky part is that in software, this phase includes making technical designs **and writing code**. Exactly, writing code belongs to the design phase. Writing code is designing.

- **Construction Phase (or Outer Loop)**: You make digital copies of that one software you have designed and ship it to your users. This is the **build and deploy** part of crafting software.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zhvk7f6n0e9hv3gk10l9.png)

And here is the problem of comparing manufacturing cars with building software. There is a misbelief that because cars are produced in hyper-automated assembly lines, building software can be automated in the same way. 

And that's wrong. In software development, when you automate something, what you are really doing is **constraining** that thing with automation. And you can only constrain a problem that is well known with a high degree of certainty.

Automation in software engineering must be applied to the build and deploy phase (i.e., the construction phase) and never to the coding phase (i.e., the design phase). Let's think about this as if it was a physics problem: data has mass, computing consumes energy, and the network takes time.
Then, you want to minimize all those variables during your creative work so it runs smoothly while you don't mind to maximize them to make digital copies of that work.

And this is where I believe that designing cars and building software is equivalent: you come up with a model that later you can copy multiple times and ship it to your customers. Again, in software, writing code is designing. That's why movements such as **Extreme Programming** promote the idea of _designing every day_.

Moreover, in software engineering bringing these two _phases_ as closely as possible with short feedback loops during multiple iterations makes it really different from other types of engineering.

## Conclusion

This idea has a corollary.

Bringing the world's best software engineers does not guarantee that you will build a successful software product that the customers will love to use. You need something else. There is a creative part that can't be neglected. In this way, building software is closer to making a movie than making a car. However, bringing the world's best software engineers will guarantee that this piece of software is built and shipped with efficacy to these customers.

That's what I think. [Follow me on Twitter](https://twitter.com/peibolsang) for more stupid rants like this! 

(Cover photo by Hal Gatewood via Unsplash)