Analogies are always useful to get into the right mindset about how things work. They are even more useful if you’re trying to explain how software engineering works to a non-technical person.
People tend to think that building software involves some kind of black magic. In reality, this process is a lot more methodical and deterministic but is difficult to explain exactly what we do to any outsider.
It’s really hard to get an accurate analogy because it’s not as deterministic as some manufacturing process like crafting chairs but it’s also not as open-ended as writing a book or painting.
We also tend to think our job is mostly about coding and doing some other technical stuff, but the truth is that the software development process is more about the successful interactions between clients, management and software engineers than any other thing.
One useful analogy that could work is civil engineering. Is simple enough that anyone can understand it but is technically consistent to make it accurate.
- You cannot estimate the real effort of a project without doing some work first. You cannot expect to go to an engineering firm and simply ask “How much will it cost to build a bridge like the Golden Gate?”.
If you’re an experienced engineer you probably do some rough estimate using the original cost of the bridge, some similar ongoing project, and some other variables but you know that these kinds of estimates are impossible to do.
Anyway, folks go lightly asking “How much an app like uber will cost to do?” and most of us want to bang our heads to the wall trying to explain that this is not how it works.
- Most estimates are bullshit and you’ll probably need a lot more time and money to build that. This is known in software. Many like to pretend estimates are written on stone but we know that they are at best an educated guess. In the construction business, this is also a thing, but they usually don’t pretend that they know what they are estimating.
For example, the Berlin Airport was estimated to cost €2 billion in 2006 and was expected to be finished in 2012. This airport is still not finished and it’s expected to open on 31 October 2020 and it will cost at least €6.5 billion to complete.
- Changing things in the middle of the project will cost a shit-ton of money and time. This is another fact most non-technical managers, product owners, and regular folks like to pretend it doesn’t exist. This is why when you’re building your home you don’t suddenly add an extra floor after 70% of the project is already done. But like I was saying, in the software industry we like to pretend is not a big deal and completely normal to add or remove 50% of the original requirements after we were working on the project for 10 months.
Like any abstraction, they are accurate to a certain degree, and there some big differences we’ll need to take into account.
- Stability of the requirements. As we saw changing the requirements in the middle of the construction is sometimes prohibitively expensive and some other times borderline impossible. That’s why you wouldn’t turn a house into a sky-crapper halfway down the project. That’s a common practice in software development.
- Stability of prices and scale. Construction has some major advantages over software development. Most construction materials have stable and known prices and can be bought in bulk even with leasing plans. The scale of the project is also known beforehand, so you can more or less get an accurate estimate of workers and machines you’ll need.
- Documentation. Even to build a little project like a house requires a hell-lot of documentation and calculations, you’ll need at least 3 different architectural plans. In most software projects documentation is non-existent or completely obsolete because it was never updated after the beginning of the coding phase.