I read every comment waiting to see if someone would point out the obvious.
This blog is 100% accurate, and nearly everyone took the wrong point away from it.
There is a very good reason we don’t build anything but the most trivial structures from Lego.
Composability and reusability are great, but not at the expense of suitability for purpose.
You could build a house or a car out of Lego, but it would be worse on almost every possible metric than a regular house (unless your primary use case for your house is to take it apart and reconfigure it easily).
The same goes for software. You could build everything from unix pipes, but that rarely happens past the most trivial scale.
In fact, the clue is in the article. Evolution is not very tolerant of inefficient systems; animals haven’t evolved hot swappable organs, they have a complex interconnected system because 99% of the time, it works better.
not literally LEGOs, but many industries are based on repeated application of basic building blocks. The simplest and most ancient example are ... bricks: you build walls by composing objects of a few standardized sizes. This sounds obvious but it's not how things were always made; if you build a wall with stones, you have to invest more time into fitting them together neatly (and often you have to use a hammer to break larger stones apart). Construction has other examples of composition of prefabricated modules.
Another example, a lot of electronics was (and still is) implemented by combining discrete components with well known behaviours (things like https://en.wikipedia.org/wiki/7400-series_integrated_circuit...). At many levels in electronics you have abstractions upon abstractions (transistors -> logical gates -> multiplexers -> ALUs -> CPUs; communication busses, etc etc)
You can build a house with bricks. But you also need adhesive. And past a certain (very low) complexity, you probably use wooden framing, cut to size. And a different material for the roof, and glass for the windows and some kind of insulation, plastics for piping, and so on and so on and so on. And that’s not even getting started on more complex buildings.
As for electronics, yep, you start with discrete components, but as you said yourself, you quickly end up with specifically designed components for efficiency.
I don't think that software reuse the goal is to be zero-glue; perhaps that part of the LEGO analogy (the lack of glue) distracts a bit.
What often happens with software development is that despite all the abstractions that get built while building one piece of software, it often turns out those abstractions can't be just pulled out and reused in another context because often those abstractions are too leaky.
I think the "original sin" stems from how "cheap" it is to write a line of code, and another one, and another one. It's not that good abstractions are never being built during software development; but when they do they usually take a long time to mature and have to be sought purposefully (and they cost way much more to engineer).
What sets software development apart from other forms of engineering is that it's often "ok" to build a house with mud and sticks that will collapse on the first strong gust of wind because ... "because it's just a POC", "let's see if we really have customers before doing it right", "making this too well has an opportunity cost of not doing something else", etc etc
The point of Lego is not the zero glue, the point is that all components share a common interface.
>>What often happens with software development is that despite all the abstractions that get built while building one piece of software, it often turns out those abstractions can't be just pulled out and reused in another context because often those abstractions are too leaky.
My question is whether a non-leaky abstraction is even valuable.
Look at a real world example of non-trivial component reuse: a vehicle engine.
It has a single purpose: convert chemical energy to kinetic energy, and they're really expensive to develop.
yet it's clearly useful to have the concept of "the engine" even if you cannot drop it in any vehicle.
E.g. it's a clear boundary between teams that collaborate on the "car" system, it's something some engineers specialize in that is quite different from "suspension system" (and such knowledge can be carried across engine design instances).
But you're right, when we're talking about LEGO-style composability, as you said, it's about having pieces that fit together and can be rearranged in many ways, and the real world is far messier and rarely you have universal composability; there are instances of "bounded" composability; e.g. the tyres for my car likely fit many other similar vehicles, but not all.
>> yet it's clearly useful to have the concept of "the engine" even if you cannot drop it in any vehicle.
Absolutely! I'm not arguing against modularity at all. I think the concept of discrete subsystems interacting is pretty much universal (organs, components, rooms, streets).
>> there are instances of "bounded" composability; e.g. the tyres for my car likely fit many other similar vehicles, but not all.
Again, completely agree.
What I'm arguing against is uniformity of interface.
You wouldn't connect a tyre to a wheel the same way you would mount an engine to a chassis.
This blog is 100% accurate, and nearly everyone took the wrong point away from it.
There is a very good reason we don’t build anything but the most trivial structures from Lego.
Composability and reusability are great, but not at the expense of suitability for purpose.
You could build a house or a car out of Lego, but it would be worse on almost every possible metric than a regular house (unless your primary use case for your house is to take it apart and reconfigure it easily).
The same goes for software. You could build everything from unix pipes, but that rarely happens past the most trivial scale.
In fact, the clue is in the article. Evolution is not very tolerant of inefficient systems; animals haven’t evolved hot swappable organs, they have a complex interconnected system because 99% of the time, it works better.