I can say how long my software compile or build time takes fairly accurately. That's the better analogy to use with construction. The rest of the software project is design work, I'm moving walls around, adding more load bearing, and so on.
But that’s just the simple stuff, the stuff without humans. Most of the time if something will take five minutes, we often try to find something to do that will take a few minutes. Well guess what, we always underestimate how long things will take, ususally by a factor of two. So a five minute build can take ten minutes for you to notice if it succeeded. And if it failed thirty seconds in, you might still be looking at fifteen to twenty minutes to the end of the second build (the more failures the lower the likelihood someone will multitask, but for some they only watch the third try closely).
This doubling and tripling is why it’s more important than you might expect for compile and test times to be very fast. An extra minute can turn into three way too often.
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. they don’t (usually) say which tools to use or how to do everything, it’s assumed you know
i don’t think these scenarios should be that far apart. those people in the skyscraper aren’t moving walls. that would screw over the whole project. they have the output of more planning so they don’t have to. and it paid off during implementation
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.
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.
But then there are, of course, all those late decisions causing major delay.
Programmers write the blueprint. The construction is handled by the computer (compiler, linker, tests).
That's a recipe for failure
> 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.
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.
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.
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.
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.