Two Wrongs

Software and Orders of Magnitude

Software and Orders of Magnitude

When discussing optimising the expensive first, we saw that software systems encompass many orders of magnitude (13, according to that Hacker News comment). What is it about software that makes the smallest so much smaller than the largest? We see this also when dealing with the complexity of software systems – the largest systems are massively larger than the smallest.

One thing that makes software special is its fractal nature. Large software is composed of medium-sized software, which in turn is composed of small software, which, of course, can be decomposed into even smaller software.

We generally don’t see this recursive nature in other things we build: we don’t build a big bridge by stacking multiple smaller bridges, for example. A house is not made by connecting together multiple independent smaller houses. Not even multi-dwelling units are made from smaller versions of itself. Imagine if building a 737 involved taking lots of little Cessnas and welding them together.

When you decompose almost everything human-made, you find the layer below looks different from the one you just pried apart. This limits both the size and complexity of the things themselves.

Software is not like that. It’s virtually limitless in both size and complexity, because we can always stick together the largest software we find and try to make something even more complex.


You may think this has consequences for software design, and you’d be right. There are at least two things we could take away from this:

I don’t know which one is the right lesson, nor whether they are mutually exclusive.