Your analogy is somewhat misguided: if you want to build a hut, you'll probably make it out of wood; a patio would be made out of concrete; a small house can be built out of bricks, although some people like them in wood too; a skyscraper will be mostly built out of metal; when built with bricks, larger buildings do generally use larger bricks; etc. "Real engineering" is not as easy and codified as software people tend to think, and there are indeed a wide variety of bricks that exist, with different structural properties. Also, most buildings these days are not actually built out of bricks; bricks are just added as an external layer for aesthetic reasons.
There are some "bricks" we have figured out in the software industry. At the systems design level, we are starting to have a very good selection of off-the-shelf database engines, state coordination systems (ZooKeeper, etcd, ...), load balancers, as just a few examples. At the program level, this depends highly on your programming language; I'd argue Clojure's data structures, for example, are really great bricks to build pretty much anything, which could be contrasted with e.g. Java, where there is no common, built-in way to represent data so everyone invents their own classes.
I definitely agree that you would expect your bridge engineer to look at the existing catalogue of off-the-shelf bricks and try very hard to use an existing variety before she starts designing her own. It does happen, though.
I think you took my analogy in a completely wrong direction. The point is not reuse, which is what you seem to be implying. The point is rather that it is better to achieve complex objective by utilizing more of the same, instead of introducing bloat. From the engineering perspective, small simple steps are always better than few giant steps.
Your analogy is somewhat misguided: if you want to build a hut, you'll probably make it out of wood; a patio would be made out of concrete; a small house can be built out of bricks, although some people like them in wood too; a skyscraper will be mostly built out of metal; when built with bricks, larger buildings do generally use larger bricks; etc. "Real engineering" is not as easy and codified as software people tend to think, and there are indeed a wide variety of bricks that exist, with different structural properties. Also, most buildings these days are not actually built out of bricks; bricks are just added as an external layer for aesthetic reasons.
There are some "bricks" we have figured out in the software industry. At the systems design level, we are starting to have a very good selection of off-the-shelf database engines, state coordination systems (ZooKeeper, etcd, ...), load balancers, as just a few examples. At the program level, this depends highly on your programming language; I'd argue Clojure's data structures, for example, are really great bricks to build pretty much anything, which could be contrasted with e.g. Java, where there is no common, built-in way to represent data so everyone invents their own classes.
I definitely agree that you would expect your bridge engineer to look at the existing catalogue of off-the-shelf bricks and try very hard to use an existing variety before she starts designing her own. It does happen, though.
I think you took my analogy in a completely wrong direction. The point is not reuse, which is what you seem to be implying. The point is rather that it is better to achieve complex objective by utilizing more of the same, instead of introducing bloat. From the engineering perspective, small simple steps are always better than few giant steps.
This approach is discussed in a bit more details here: medium.com/digital-exprt/https-med...
Definitely agree that composing small, simple things is better than building one large, complex one.
Yes, bloat is the bane of our profession. As soon as you task any dev team to get something done, they always deliver spectacular bloat.