I’ve been thinking for a while on why software crashes a little more often than, for instance, cars. Meanwhile, the engineering resources behind the automotive-industry and the software-industry are not that different at all: They both have great engineers, design tools and a solid-science among others; however, we still get to crash software more often than cars.
There is, however, one subtle difference in the software world: Once we build one “car”, we are done! We have the luxury of duplicating our “cars” for free, is as simple as right-click-copy followed by right-click-paste. However, on the automotive-industry, you just don’t get to copy-paste cars; in fact, after engineers build a working car, they are still far-far away from producing cars in mass scale.
The physics of the real world force mechanical engineers to carefully minimize costs, each “line of code they write” has an associated cost. Not even that, but the process which assembles “modules of code” needs to be carefully designed to ensure that the assembly-line is efficient, cost effective and reliable.
We (software engineers) get to write as many lines of code we want and we get to assemble modules of code, ourselves and only once!
Now, we’ve come a long way to realize that overtime, this process does not scale. Code becomes too interdependent, unstructured and therefore, hard to maintain (we call this spaghetti code, although is not as tasty; think of it as rotten-spaghetti instead). Therefore, we’ve developed: best practices, good designs patterns, reusable units, we test those units, we document them, we review them, we run stress and performance tests, we inspect them using reliable processes, we even measure how much we are testing (we call this code coverage) and we keep improving over and over again.
But see, there is still one problem: We are still building (very diligently and professionally) a single car, just one. We just don’t have the cost and challenges associated with building an assembly line. So what’s the big deal? It was built diligently and professionally, right? Right! However, the economics of our manufacturing process are very different than theirs.
Here is an example: You are launching a new product on 1.30.2020 and you find out a severe defect on 1.15.2012. Schedule is tight, risk is high. The engineering team gets together and finds two solutions: The first one involves increasing a fluid container by 20% and reordering several components around it. The second one involves adding an additional container that does not require reorganizing additional components at all. The “correct” solution is expensive and jeopardizes the launch day; however, the ad-hoc extra-container avoids any redesign and proves to be as reliable as the “correct” approach. Do you see where this is going?
Now, with no manufacturing restrictions, one can ship car updates every month and with them, ship the last minute ad-hoc fix as well. You can find a process to avoid re-shipping the ad-hoc fix pattern on the next iteration; however, the fundamental problem is that the economics of software and manufacturing are not the same at all.
However, if we embrace production costs, we will build factories, not cars.
Javier Luraschi 