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.

Two Fridays away at 11:05 a concrete truck turns up and pours. At 13:10 something is laid by some specialist in the concrete. At 14:50 another thing happens.

I asked her if she was joking and she looked at me like I was mad. Of course not. The concrete needs to be poured and then the truck goes somewhere else. When it hardens a thing has to happen and then the guy who checks the thing turns up and they’ve only got him for half a day and so on and so forth.

My mate says that “if they built bridges like we built IT infrastructure a lot more people would die”.

If people regularly died because of IT infrastructure, we'd be regulated and licensed like civil engineers and we certainly wouldn't be writing software in C/C++/nodejs. We'd all be coding in stuff like Ada and Erlang and most of our day wouldn't involve writing logic at all - it would involve filling out documentation and forms around the occasional bit of logic that would get written, probably by someone else.

My father-in-law was in commercial construction for decades, now turned general contracting post 2008 recession, and he has binder and binders of contractor business cards, including a concrete section. I can assure you project managers would be frantically calling all concrete companies trying to find a replacement. And they will.

There are not just concrete trucks just lined up down the road, waiting for a PM to say “okay we’ve got enough, you can stop now”.

The amount of concrete is known. It is planned. The 3rd party concrete supplier is given an order well ahead of time. They plan their trucks and drivers. None of this is made up on the day.

One of them having an accident matters.

This is why IT projects are such a shambles. When we forget something — a change request, say — we just say “oh well, that’s a pity”. Some poor schmuck has a bad afternoon running around making it good and life goes on. We get away with it because it isn’t concrete in a truck.

One truck can deliver about 8 m3 of concrete. If you need 100 m3, that's about 12 deliveries.

This can be done if 4 trucks make 3 deliveries each, or if 3 trucks make 4 deliveries each. The supplier has several trucks and while each one needs maintenance rarely, the fleet of them needs maintenance almost daily, so the supplier is likely to either over-provision (have a spare truck), or be able to procure one from his competitor across the street. "One of the trucks having an accident" is already planned in on the supplier level.

Risk management. Which in the real world actually means something, unlike those horribly pointless risk workshops your PM makes you turn up to.

The work package that contained the concrete truck would have assigned to it a risk. These risks have been carefully thought out ahead of time. I dare say in the building industry they re-use them. What an idea! Learning from your past. Anyway.

So the risk here is that ‘the truck gets stuck in an accident’, and that risk has a rating. An amount of money is assigned as a reserve to this risk in the event that it happens. This money is part of the project’s budget but ideally you never spend it. But it’s there.

So if the bad thing happens — freeway accident — the PM pulls out their risk register, looks it up, calls the boss, says “hey that risk eventuated, we need to use that reserve”, the funds are released, and the risk mitigation is initiated.

https://en.wikipedia.org/wiki/Takt_time

Maybe it's just me, but having my reputation staked on my estimates with an easy to read chart of dependencies and deadlines helps me 'servo' my effort(i.e. work overtime) and come in closer to the estimate.

I wouldn't suggest that for everyone, but some of us like that sort of pressure and the feeling that comes with nailing it. Then again, I don't have kids.

Management always tried to ride them like it was sheet music for an orchestra. This has to be done before this, so we’re going to schedule one to start the day after the other finishes. Sure. This whole scheduling process is a farce so I’m now entirely checked out, so it’s just going to get worse as the meeting goes on.

I'd argue that the dedicated project manager was much more important for success than the Gantt charts.

If you are asked to write the same exact piece of code (like each floor) 18 times you'd probably have no problem meeting schedule.

Maybe it didn't happen that time, or maybe it did and they remediated somehow (at higher cost), but I have a dataset that says it happens all the time. And that "it can't happen" attitude is part of why it actually happens- nobody is looking ahead at uncertainty.

Writing software is the equivalent of creating the blueprints; compiling is the equivalent of pouring concrete.

Add things generally go according to plan in Western countries so I'm not surprised. (I'm from a non-Western country where long term planning of anything is futile — too much entropy and chaos).

Computers, software etc is a very young field in comparison. By the year 4723 things would hopefully be standardized (and possibly build themselves).

Knowing this, one could say that its a minor miracle anything gets shipped in this industry.

He said of course they can finish, they have an entire week. Apparently he was incredulous. How does that NOT point to a week being more than enough time?

I only ask, because, well, that was my question originally, and, well, because your question does nothing to answer that question.

So, have you? Or are you just another online bystander?

I can think of maybe 3-4 over the last 20 years. How common are they in the developing world? that'd seem to be a much higher number.

Citation needed…or not. It’s an obtuse claim on its face.

I’d argue corruption is an inherently corrosive influence, and the necessarily large bureaucratic apparatuses involved with things like large construction projects are particularly vulnerable to corruption.

You are absolutely correct that large construction projects are very vulnerable to corruption: Anything that has as high a budget is going to be rife with opportunities. But a project's culture will alter the kind of corruption you get. I was quite close to the construction of bridge spanning over a river, a little under a mile wide. Significant slippage in the delivery date was going to be very annoying to the powers that be: Being able to finish the construction prior to the next election was important, and being seen as the cause for a delay was going to lead to losing more projects that some of the very same people were going to keep overseeing in the future. So the bridge was done on time. It's just that a lot of palms got greased, and extra 'cement money' really went into things it shouldn't. For instance, the bridge's main engineer had just bought a derelict house that was completely restored by 'elves', from the construction company.

Sometimes the fact that something took 4 years too long is tolerable to the powers that be, while the construction definitely remains safe. Other times, the construction is just going to prove really faulty in 15 years, because things didn't go over budget, and someone took the difference between what the spec called for, and what could possibly appear to be a completed project.

Same with permitting. In some cities, corruption means you don't let people build something because you don't want it. In others, the mayor tells their friends to buy land zoned for low density, and then rezones to let them build 20 story buildings, making a mint. Still corruption, but different parts of a project suffer the consequences.

Only truly cursed projects manage to take 4 times as long, 20 times the costs, and end up with something awful in the end.

Shenzen was a rice paddy in 1990 and two decades later was a city of 20m people (2nd highest number of skyscrapers in the world too). The exact reason why China have been able to do this is the reason why you think it is impossible. People in the west are too lazy, too self-indulgent, too anxious about what other people are doing...China did it, they aren't paying attention, they don't care, they didn't ask anyone for permission, they just did it. In the time it takes to build a road in the US, they built a city with one of the most productive economies on the planet...where do you think the future is?

Totally off topic, but is this a normal usage of this phrase? I've never seen/read "get jumped up" used in this sense.