The software equivalent is adding infrastructure components to your project because on one level they help you towards the goal of what you are trying to build, but "no free lunch" applies here too, and there is a downside in terms of overall complexity, debugging times, build times, maintenance cost, etc.
Maybe "no free lunch" and/or "technical debt" already express it, and we don't need a new "weight adds weight" way to describe it, although there is something about the tautological inevitability of it that is a valuable reminder.
Akin's Laws¹ of Spacecraft Design have a few relevant ones:
> 13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.
This is not the only one that's relevant. Also 15, 27, 33, 34, 36, 36, 38, 44, and, if you substitute "distributed architecture" for "launch vehicle":
> 39. Any exploration program which "just happens" to include a new launch vehicle is, de facto, a launch vehicle program.
Of course, if a staged design is actually required (and not just because your engineers need to buff their CVs so they can jump out when the project fails under its own weight):
> 41. There's never enough time to do it right, but somehow, there's always enough time to do it over.
Sometimes "throwaway work" is still worth doing. Maybe you can spend one month hacking an important feature into the old architecture, to deliver it early while investing 6+ months of work into The Right Way. Deprecating the first version is like dropping a rocket stage.
Adding architectural complexity leads to growth in developer headcount. This requires more support staff, and more communication complexity. The growth follows a superlinear trend, as does the fuel requirement for larger rockets.
Let’s say we have one server running our stuff, and it’s too slow.
One option is, upgrade the CPUs or add more RAM. This seems analogous to “build a bigger engine” in your example. There’s no added complexity (well, mostly, maybe you run into NUMA issues or something).
But some kinds of upgrades are more costly or complex than they appear on the surface.
If we want to add 1 TB of usable storage space, at the physical level that means multiple drives for redundancy, keeping multiple copies of the data for backup, keeping replicated copies of data that are ready to turn on at any moment, and so on. So in the developer’s mind we think “add a single 1 TB drive”, but in reality it might take adding 15-20 drives in numerous servers to accomplish this.
The same thing happens when going from a single physical server to multiple. With a single server you can scale vertically. But horizontal scaling is a different type of complexity, now having to think not only about server redundancy, but redundancy at the network layer, now you need redundant network switches, and it all needs to be configured right to handle any part in the communication path failing (server down, server network card down, server network card port down, bad network cable, network switch down, network switch port down), and all of those require some configuration and protocols, and maybe you’re not familiar with VRRP or LACP on the network switches and also how those interact with VMware load balancing and failover, so now you need a VMware person and a Cisco person and that’s not even considering how you handle split brain scenarios where both servers are still running but can’t talk to each other due to a network partition.
And that’s all a very different kind of upgrade than slapping more RAM sticks in the server and keep rolling.
(Chin stroke): I think the key metric for insights on the web isn't whether they're accurate, but whether you can sound smart when repeating it to someone else.
(Not saying I approve of this)
Thinking about my poor heavyweight rocket that barely makes it to orbit and when I compare them to the sleek elegant designs by Scott Manley that makes it to Mun and back and. Sigh.
Brooks v2
How to articulate that in a pithy way? I do feel that when you have a lot of technologies interacting on a project, even if they all worked well together initially, in five or ten years time the whole thing does have a very rocket equation like punishing curve for return on maintenance effort. Perhaps something like "Over time, maintenance effort approaches exponential scaling with the number of interacting technologies."
Ah! I got it. What's going on is that external dependencies are a source of chaos, as maintenance and security issues and expertise requirements flow from that project into yours. So...
"Dependencies cause multiplicative bit rot."