Buildings are typically cookie cutter designs that aren’t too different. The ones that are have all the same problems - you have to adjust the design on the fly (see Burj Kalifa).

Additionally, when your in the middle of creating your building, the owner doesn’t come in and say “actually, I want this apartment complex to also have a suite of luxury condors on every odd floor”.

It’s a fantasy to think that more planning would make software development cheaper or more on time. We tried that. That’s waterfall. And it failed miserably because software supports business needs which change on a quarterly or yearly basis. Not to mention that we need to update our software to take advantage of newer systems or security vulnerabilities. That building you’re putting has a fixed purpose that’s going to remain largely unchanged for 50 to 100 years or so, there’s generally nothing new to learn in terms of techniques and problems (unless your pushing things like with Burj in which case they did have to make on the fly adjustments and delay), and doesn’t have to deal with the challenges of the virtual space that software plays in.

So sure. If you’re a contractor building the same kind of website over and over again, I’m sure you can give a very accurate estimate of how long a given piece of work can take. If you’re trying to build a more scalable system or something totally new that hasn’t been done before, then there’s no plans to follow and you have to iterate until you figure out solutions to all the problems you encounter.

"Additionally, when your in the middle of creating your building, the owner doesn’t come in and say “actually, I want this apartment complex to also have a suite of luxury condors on every odd floor”."

From what I've heard from people working in the construction industry, this sort of thing ("variations" I gather they're called) happens more than you'd think.

A better example would be owner saying “actually, I want a 5-level underground parking below my building”.

At the same time the plans typically allow quite a lot of flexibility and are made in a way to allow late decisions on many aspects.

But then there are, of course, all those late decisions causing major delay.

Sometimes owners do want changes after construction began and some of those buildings collapsed in spectacular manner…

A software project's design doc is like an architectural mock-up: sometimes useful, but not necessary and certainly not part of the construction process.

Programmers write the blueprint. The construction is handled by the computer (compiler, linker, tests).

> compare this to a software team that has plans (design docs) for everything they want o build. they have schematics (tickets) that say do this here. to this exact interface.

That's a recipe for failure

This is such a tremendously ignorant (and frankly harmful) take that it was hard to resist downvoting you. Either you have no idea how software is actually built, or you have worked for some deeply dysfunctional companies and you have my deepest sympathies. If you have any semblance of authority over any software developers, then my sympathies go toward them instead, for having to deal with you. Yes, it's that bad.

> compare this to a software team that has plans (design docs) for everything they want o build. they have schematics (tickets) that say do this here. to this exact interface.

Missing from your description is who is writing those precise plans and tickets that specify exactly what needs to happen down to the "exact interface", whatever that's supposed to mean. Whoever's writing those is your actual software developer, and they're wasting their time. If they already know exactly how the code should work, writing those documents takes longer than just writing the code itself. Throw the documents away and just write the goddamn code. Everyone else is doing literally nothing. What you described is not software development, it's a nightmare-creature feeding on wasted hours and crushed dreams.

If software engineers get too comfortable with one framework or tool a bunch of them will just try something new or some new paradigm since they're bored. This has always been a source of delays in projects I've seen, not sure what the construction equivalent is.

The other side of this conversation is that construction does get delayed or not finished. Talk with anyone that has built a house and they'll have horror stories of months of delays. Commercial is the place to be for construction, residential seems like endless issues up and down.

> Talk with anyone that has built a house and they'll have horror stories of months of delays.

This can easily be explained in the part of the world I live in. Small/medium construction companies prefer to work on bigger projects than a house for obvious reasons. So they'll come over and do parts of your house in between jobs on the bigger sites which freqently means massive delays.

> If software engineers get too comfortable with one framework or tool a bunch of them will just try something new or some new paradigm since they're bored

I often wonder wether this is because software is such a new field (people have been making houses for millenia), or because of the kind of people software appeals to?

Many other professions are much more interested about providing services in time and reliably, than about innovation.

Not even that extreme. Some of our development tools are *really bad*.

I have yet to be anywhere that used Jenkins and didn't make me want to throw the computer out the window with the amount of delays it introduced.

I hope you're not a manager.