Software developers are able to build abstractions out of thin air and put them out into the world incredibly quickly. The value proposition of some of these abstractions are big enough that it enables _other_ value propositions. The result of that is that our "materials" are often new, poorly documented, and poorly understood. Certainly my experience writing software is that I am asked to interact with large abstractions that are only a few years old.
Conversely, when I sit in a meeting with a bunch of very senior mechanical engineers every one of them has memorized all of the relevant properties of every building material they might want to use for some project: steel, concrete, etc. Because it's so static, knowing them is table stakes.
I'd say this difference in changing "materials" is a big source of this discrepancy.
The big difference is no one really tries new things that often in construction, because for the most part people have enough difficulty just making the normal run of the mill stuff work - and people who have the energy to try often end up in jail or bankrupt.
In Software, we’re so young we end up doing mostly new things all the time. Our problems are simple enough and bend to logic enough too, that we usually get away with it.
If you’ve ever poured a footing for a building, then had the slump test fail on the concrete afterwards you’ll sorely be wishing for a mere refactoring of a JavaScript spaghetti codebase under a deadline.
Buildings neither are Turing complete, nor do the building blocks become obsolete every few years.
The closest analogue to software development is legislation.
Even the best written rules can have unintended consequences, and so we have tools to make the behavior ever more precise and less error-probe. But it’s never fool proof.
Also and like legislation, it’s the edge cases that balloon a proof of concept into monstrous sizes.
In some respects, for software to advance some components need to be less powerful. But we have this fetish for inventing yet another Turing complete language in the pro space, just because, and bolting on a million features.
It’s unnecessarily tiresome.
They’re also using literally thousands of years of deeply ingrained cultural rules and expectations focusing on making living in and building structures effective (it’s one of the core tenets of civilization afterall), supported by an army of inspectors, design specialists, contractors (themselves leveraging thousands of years of passed down and deeply baked in expertise in everything from bricklaying, to concrete work, to framing).
All that for what, functionally, is a box we put things in, including ourselves, that we prefer provides some basic services to a decent standard and isn’t too ugly.
You'd design and build a building, and that was it. If the roof leaked (common on building-like pieces of art), you didn't want to know about it. If the interior was changed to actually work for the buildings occupants, you didn't want to know -- that'd mean that your beautiful design has been marred.
All this suggests to me that some of these designs are done without deeply considering the needs of the people affected, and realizing that those needs change, and worse, without learning from the mistakes and successes of the past.
[Note that I am not arguing about the merits of how software is, was, or should be designed.]
If architects could build a house multiple times a day while slightly rearranging the layout every time they'd do that in a heartbeat.
There are natural-intelligence (human) agents translating the diagram to "code" (bricks).
There is a lot of problem fixing going on done by the construction crews, cursing at the architects (sometimes, or just going with the flow and what comes with the job).
That is the same with software:
If you give good developers diagrams those human agents too will be able to produce useful software from it, no matter the flaws in the diagrams, as long as they understand the intent and are motivated to solve the problems.
The goal of 3d printing and the like is to make mechanical engineering more like software so you can get a tight iteration loop
Writing code is very close to what 90% of the drafting work is for construction (aka some relatively junior person figuring out exactly how many bricks would fit in this space, and how thick it would need to be, to meet the requirements his senior person told him he had to meet - and trying a couple other options when that is obviously BS that doesn’t work the first few times, and then everyone refactoring things when it turns out the first idea causes too many issues and the architect’s grand plan for a 50 ft open span in an area is impossible with current materials).
More modern systems like LuaJIT, SpiderMonkey, and HotSpot are even more radical, constantly tearing down and rebuilding parts of the machine code while the program is running. Programs built with them are more like living things than buildings, with osteoclasts constantly digesting bones while osteoblasts build them. In these systems we just send the plans—our source code, or a sparser form of it—to the end-user to be gardened and nurtured. Then, just as osteoblasts build denser bone where its strength is most needed, the JIT builds higher-performance code for the cases that automatic profiling shows are most performance-critical to that user.
— ⁂ —
Soon architects will be able to do their work in the same way.
Like Microsoft programmers in the 01990s, they'll do a "nightly build" of the current design with a swarm of IoT 3-D printers. Consider the 10,000 tonnes of structural steel that make up the Walt Disney Concert Hall in Los Angeles, which seats 2265 people. After the 16-year construction project, it was discovered that reflection from the concave surface was creating deadly hot spots on the sidewalk and nearby condos, requiring some expensive rework.
If each assembler can bolt a kilogram of steel onto the growing structure every 8 seconds, then 2000 assemblers can rebuild it from source in a bit over 11 hours. In the morning, like programmers, the architects can walk through the structure, swing wrecking balls at it to verify their structural integrity calculations, and see how the light falls, and, importantly, notice the sidewalk hotspots. Perhaps another 2000 printers using other materials can add acoustic panels and glazing, so the architects can see how the acoustics of the space work. Perhaps they can try out smaller changes while inside the space using a direct-manipulation interface, changing the thickness of a wall or the angle of an overhang, while being careful not to stand underneath.
In the afternoon, when the architects have gone home, the assemblers begin the work of garbage collection of the parts of the structure whose design has been changed, so the next nightly build reflects the latest updates. As night falls, they begin to rebuild. The build engineer sings softly to them by the moonlight, alert for signs of trouble that could stall the build.
— ⁂ —
Today that isn't practical—the nightly build machine for a single architectural firm would cost several billion dollars. But that machinery itself will come down in cost as we learn to bring the exuberant living abundance of software to other engineering disciplines.
To do ten "load builds" in the 16 years the Walt Disney Concert Hall took, you'd only need two assemblers, perhaps costing a couple million dollars at today's prices; they'd be able to complete each successive prototype building in 15 months.
Suppose prices come down and you can afford 32 assemblers, each placing a kilogram of steel every 8 seconds. Now you can do a "monthly build", which is roughly what I did when I joined a C++ project in 01996 as the build engineer. Or you can build 10:1 reduced scale models (big enough to fit 22 people, in this case) a thousand times as fast. Incremental recompilation on the C++ project allowed individual developers to test their incremental changes to the design, and similarly this kind of automation could allow individual architects to test their incremental changes to the building, though perhaps not all at the same time—the full-scale building would be like an "integration test server".
Suppose prices come down further and you can afford 512 such assemblers. Now you're not quite to the point of being able to do nightly builds, but you can do a couple of builds a week, and you can rebuild a fourth of the Walt Disney Concert Hall overnight.
Suppose prices come down further and you can afford 8192 assemblers. Now you can rebuild the building several times a day. You can totally remodel the concert hall between the morning concert and the afternoon concert.
Suppose prices come down further and you can afford 131072 assemblers. Now you can rebuild the concert hall in 10 minutes. There's no longer any need to leave it built; you can set it up in a park on a whim for a concert, or remodel it into a cruise ship.
Suppose prices come down further and you can afford 2097152 assemblers. Now totally rebuilding the concert hall takes about 30 seconds, and you can adapt it dynamically to the desires and practices of whoever is using it at the moment. This is where modern software development practice is: my browser spends 30 seconds recompiling Fecebutt's UI with SpiderMonkey every time I open the damn page. At this point the "assemblers" are the concert hall; they weigh 5 kg each and link their little hands together to form dynamic, ephemeral structures.
Suppose the assemblers singing kumbaya shrink further; now each weighs only 300 g, and they are capable of acrobatically catapulting one another into the shape of the Walt Disney Concert Hall, or any other ten-thousand-tonne steel structure you like, in a few seconds.
(Wouldn't this waste a lot of energy? Probably not, though it depends on the efficiency of the machinery; the energy cost of lifting ten thousand tonnes an average of ten meters off the ground is about a gigajoule, 270 kWh; at 4¢/kWh that's US$11. In theory you can recoup that energy when you bring the structure back down, but lots of existing technology loses a factor of 10 or 100 to friction. Even at a factor of 100, though, the energy cost is unlikely to be significant compared to construction costs today.)
— ⁂ —
But tell me more about how programmers need to plan more to reduce the cost of construction mistakes?