Software Development Has Diseconomies of Scale

But it's seductive for a reason : it's true. Doing regression tests on this scale will protect you from quite a sizable class of bugs. BUT there is no way to write lots of tests without locking down the implementation of the program. If you limit yourself to black box testing (meaning either no unit tests, or breaking and replacing unit tests is encouraged) you can retain some flexibility for a while. You want to be in the situation that if I go into an application and replace one algorithm with an equivalent one at any point in the app, none of the tests fail. I have never once seen any testsuite do that correctly. In most cases tests complicate an already complex codebase.

This leads to having to choose between 2 approaches : either you ignore tests results (which of course does result in bugs), or you always fix tests (which of course leads to the tests becoming tautological over time as different people "fix" them and results in both more effort AND bugs).

I don't disagree that for some software locking the functionality down is appropriate. But not for line of business software, apps with large UIs, essentially anything consumer facing ... It is only appropriate for standardized infrastructure software, things that manage accounts, process payments, regulate a power plant, avionics, ...

> Finally, I increasingly wonder where else diseconomies of scale rule? They can’t be unique to software development. In my more fanciful moments I wonder if diseconomies of scale are the norm in all knowledge work.

They apply to every known form of manufacturing, such as vehicles or genetic engineering of vegetables (the more parts of a vegetable you try to engineer, the more difficult it gets). The author seems to have missed this, which is what I was pointing out.

And on the idea that even developing software does not have economies of scale, I present the following: Linux. Linux is what we build everything on top of. Without Linux, we'd have to start from scratch. Linux is just code. Databases are the same way. We build our applications on top of thousands of lines of code and we utilize the economies of scale of everyone building off the same code to make our code easier to create.

So I'd say that not only does software have economies of scale in distribution, it must have economies of scale in production or we would not have operating systems or databases. The issue he is dealing with is a simpler one - complexity is hard to manage.

If you manage your complexity well and create a Linux or an Apache web server, then you have economies of scale. If you create a ball of mud, you have diseconomies of scale. If you build your 1km long truck out of well designed modular blocks, you have economies of scale in transporting massive amounts of goods along flat roads. If you try to custom build the whole 1km of truck, it will be a disaster. Nothing unique to software here, and diseconomies of scale are a failure of software design, not an inherent property.

Choosing these separation points is not trivial, by the way. It usually requires many iterations and a good gut feeling for what future requirements may arise. One example that is frequently mentioned is content vs form, for example website content and its presentation. It's useful, but still strongly depends on the actual uses. What works on screens doesn't necessarily work on paper. Not all forms can accommodate any kind of content. In other words the content also needs to fit the form. Or see how the layered model of the TPC/IP or the ISO-OSI protocols actually isn't that principled in practice. A high-level protocol may want to adjust its workings depending on what lower-level protocol it is running over.

So decoupling is not trivial. It often reduces performance too. Say you want to chain two tools sequentially. What if you end up using a specific combination 90% of the time, but there is some intermediate step in the first component that calculates something that is thrown away and the second component needs to recompute it because the general interface between the two doesn't include passing that data along? Then you can either accept it, or tightly couple them, OR even worse: you may try to find the real pure elegant reason for why this piece of data is actually logically required there and then you end up with abstractions that only have one instantiation, just for the sake of not "hard-coding" things.

But anyway, back to the core issue. There is not much to be surprised about.

Complexity of system = Complexity of individual components + Complexity of their interactions

This is analogous to the decomposition of the variance of a set of numbers: total variance = variance inside groups + variance between different groups. There is also some physical analogy for calculating energies, where you need to take couplings into account.

If you have a big system you need to take care of lots of interactions. If you choose to use small independent tools, then you need to write the code for their interaction.

Should the components come from the same vendor or different ones? There are arguments for both. Use same: they tested all sorts of interactions and fixed any bugs that they found (Apple supporters often point to this). Use different: each component only cares about its job, so less bugs in them, clear responsibilities etc. Certainly, if the same vendor develops all components of the system, they don't have to be so conceptually clean and they may make up for bugs in one subsystem by quirky code that tries to cancel out the bug's effects in some other subsystem, leading to fragile software.

To see how software is like milk, you have to compare writing custom software for each and every client vs. writing one product and deploying this same program to all clients.

The analogy of mass production for software is when the same operating system runs on millions of machines.

However, the author of the article suggest that the equivalent of mass production is when a piece of software takes on a lot of responsibility, and gets bloated with features. But that's a totally different issue. When you compare ten cartons of 1 pint milk vs one carton of 10 pints, then you are dealing with indistinguishable ten cartons.

If you want a real world metaphor that's like software complexity, you could rather use recipes. Elaborate, complex recipes don't scale; just like software. There it's not trivial to put the non-indistinguishable ingredients together. With milk, it's just pour all the milk in one big container. There is no additional thinking required.

TL;DR author compares apples and oranges.