The Tyranny of ‘The Plan' (2013) | Hacker News Reader

The Tyranny of ‘The Plan' (2013)

chrisgagne.com

125 pointscangencer53 comments

I found the OP very insightful, and would recommend reading and thinking about it. The lessons we can draw from the construction of The Empire State and other buildings of that era, before the advent of computers, are applicable to any large, capital-intensive project.

My only reservation is that the OP fails to mention that some workers died during the construction of The Empire State building: According to the builder, "only" 5 workers died, but according to a newspaper, 14 workers died.[a] No one in the developed world would want to finish a project faster and for less money if the cost has to be measured in human lives -- expect in extreme circumstances, like war.[b]

[a] https://en.wikipedia.org/wiki/Empire_State_Building#Construc...

[b] In some parts of the world, projects are routinely finished faster at the expense of human lives. For example, according to https://www.theguardian.com/football/2022/nov/27/qatar-death... , between 6,500 and 15,000 workers died, and more were injured, to build all the stadiums and facilities in time for the World Cup in Qatar, a tiny country in the Middle East / Western Asia with a total population of under 3M people.

EDITS: Added " -- expect in extreme circumstances, like war" to the last paragraph, and a link to Patrick Collison's fantastic page with examples of "people quickly accomplishing ambitious things together" and thoughts on why projects take so much longer today.

> No one here would want to finish a project faster if the cost would be measured in human lives.

People—including some here—choose risk to life for greater productivity, all the time. Every advocate of going back to the office, in places without excellent public transit or walkability, is proposing to trade some serious micromorts for extra productivity (driving's dangerous).

I think there's a pretty clear line in many places in today's western world about the difference between "directly causing death" and "causes fractional death."

So comparing "directly dying from construction" to "commuting in a car" is a big reach.

Diet, stress, physically-taxing-if-not-directly-fatal jobs, cancer-linked chemicals, pollution, etc. Tradeoffs made at both the societal and individual level every day.

Even in cars, consider the difference in attention "death from direct failure of the vehicle or manufacturer" gets compared to the more-random "accident that could've happened to anyone" increased-death-probability cases.

And that ties us neatly back to construction! We have many more things in place for construction safety - from regulations to equipment to practices - but it doesn't prevent there from being any loss of life, still. We just don't want to go backward.

All death is "fractional" if you make a fraction out of it. For example, dividing the number of people that died making the Empire State Building by the total number of workers. It seems subjective which fractions matter and which don't. It seems to be based on how much the responsibility can be laundered.

i don't understand why you think directly dying from having a steel i-beam fall on you is so different from directly dying from having a toyota hilux t-bone you in your civic, but you say it's 'a big reach'

aren't these both random 'accidents that could've happened to anyone'

do you maybe think that the foreman on a construction site sometimes picks one of the employees and orders him to get killed that day or something

Ill never forget;

I was a Title Runner when I was 18 in Reno. The Clarion had been purchased, and renamed Atlantis - and they were adding on/remodeling it...

I was driving by and there was a crane lifting a pile of I-Beams to the top of the tower... and as I was driving, I looked and thought "Damn, that would suck if they dropped that"

THE CABLE IMMEDIATELY BROKE and all the beams fell like 15 stories!!!

I got really freaked out and said "Ill never focus on disasters like that again."

Luckily nobody was injured, but I was mentally scarred.

"Pre-emptive Health Neutralization" was one of the names for the CIA's kill list eras (they always change the name for the kill list such that it compartmentalizes and rewrites the history of what is being said (narrative) - I believe that one was Reagan's name for it. I believe the kill-list name changes with each POTUS as stated by Annie Jacobson

https://www.youtube.com/results?search_query=joe+rogan+annie...

Apparently there was a historic increase in US road fatalities in 2020 and 2021 instead: https://en.wikipedia.org/wiki/Motor_vehicle_fatality_rate_in...

Maybe having more food delivery guys on the road is worse than more commuters, for public safety? Let's wait and see how 2022 did.

So I work for a major insurance company, and though I'm not involved in the "insurance" aspect of it, it's been said during large corporate-like meetings that the reason is that vehicle during the pandemic were going a lot faster, probably because of less vehicles. My understanding from the people who sell auto insurance is that less cars yields more intensive accidents, albeit if fewer. Interestingly enough the numbers work out that car insurance payouts have been a lot less profitable during the pandemic because of it, because the crashes are more damaging.

That's hiw I understood it from the guys who's job it is to make money by selling auto insurance anyways.

Would you trade a dozen workmen's lives to get a development project done in under one year, rather than two? Are there actually many examples of tech businesses doing this right now? It doesn't seem to happen all the time. You're comparing multiple fatalities on a single year project to micromorts.

Yeah, and that's a big problem, that leads to people not really having the choice at all, because they are forced to keep up with people who value productivity over safety.

"No one in the developed world would want to finish a project faster and for less money if the cost has to be measured in human lives -- expect in extreme circumstances, like war."

Are you sure of that? If the pandemic brought me any surprising new insight, then it would be how big the part of any given population is with hundred thousands dying if it just inconveniences them a little less. It needs no war, it needs people not being able to go to the hairdresser for a month.

Your example deals with something completely different. This issue is more akin to the meatpacking workers' deaths, which were very high at some companies. It does generally does happen in extreme circumstances, or when some singularly evil engineer / executive / firm is in charge. Your typical person though remains not a psychopath.

https://www.history.com/news/mohawk-skywalkers-ironworkers-n...

[warning: auto-play video]

It is an interesting history of the Mohawk ironworkers who built NYC. I came across another exhibit once that said that the ironworkers originally took the jobs because, culturally, they appreciated the risk and heroism, and then it became a tradition of the tribe. In fact, it was probably this risk tolerance that kept them working without harnesses and lifelines for as long as they did.

At the end of the above article, it says that 30-50 ironworkers still die each year.

That casualties number for the Qatar WC does not present an accurate picture. That number of deaths is the total number of expat deaths during the period of construction. It's not just workers in stadium construction.

"Overall, 15,021 non-Qataris died in the country between 2010 and 2019, according to the government. A Guardian analysis in February 2021 found that more than 6,500 migrant workers from India, Pakistan, Nepal, Bangladesh and Sri Lanka had died in Qatar since the award of the tournament. The death records were not categorised by occupation or place of work."

It's a normal number considering Qatar's 3 million population is 90% expats.

14 deaths out of ≈3500 workers over 18 months is a death rate of 270 per 100_000 per year, or a life expectancy of 380 years

this is about ten times the average death rate for young people today but it still doesn't seem like an unacceptably dangerous workplace environment in the sense that if you worked in an environment that dangerous all your working life you'd still make it to retirement age with about 90% probability

that's a similar level of risk to smoking cigarettes, but of course you can't make a living smoking cigarettes, so i think skyscraper construction is somewhat more morally defensible

we aren't talking about the mines of potosí or something here

> No one in the developed world would want to finish a project faster and for less money if the cost had to be measured in human lives.

Depends. I think the Manhattan Project killed more people (not including using the bombs in combat).

Possibly including John von Neumann, one of the greatest polymaths ever. Everyday life now would be different if he had lived to a normal life expectancy instead of dying to aggressive cancer at 53.

Louis Slotin was a scientific hero for myself as a young person.

Good point! I added " -- expect in extreme circumstances, like war" to the last paragraph. Thank you.

I strongly suspect that the excellent planning behind Empire State led to less deaths than equivalent towers from that time.

BLS says that roughly 5000 people die in construction accidents annually. those deaths are certainly tragic, but not disproportional.

Ordinary house roofing work (and, by extension, things like rooftop solar installations/maintenance) is terribly dangerous. Tons of deaths and serious injuries per year. Little attention on it at all, let alone political movement toward making it safer.

Isn't this partly because roofers rarely take the full "correct" range of safety precautions while working, because they would significantly slow down the work?

It probably also has to do with the fact that most of the work is small contractors, many without even a business license or insurance, or even just the homeowners themselves. Ironworkers deal with big structures where the financing demands large business entities and therefore usually unions, both of which are typically fanatical about worker safety.

Also because a lot of them are of the "hardhats are because we live in a nanny state" and then fall off a roof or fall backwards on the ladder, because they are fabulously un-self aware, DAD

There is a mini documentary on the conditions of the workers of the world cup qatar stadiums...

WRETCHED! I FN HATE the the world cup (FIFA) --> one of the most corrupt institutions.

The conditions of the living quarters for the workers for FIFA on the world cup builds are horrific.

Plus, they wouldnt pay the workers, would seize their passports and beat them.

No safety equipment, and extremely hot working conditions. Some of the temps were as high as 125F and these guys are doing really hard physical labor.

Actually there are a bunch of vids on the conditions:

https://duckduckgo.com/?t=ffab&q=working+conditions+of+build...

The assumption here is that the speed caused the deaths and that’s not necessarily true. We have better safety practices now like hi-vis vests, tie-offs, etc. They don’t slow things that much. I think we could build just as fast without deaths with modern materials and machines.

I wonder how much longer the Empire State Building construction would have taken, or what other compromises would have been required (fewer floors, less ornamentation, etc) in order to prevent those deaths.

I loved this, and in particular how to think about teams, experts, and workstreams. But the physical construction (in my experience) has a limited number of software analogs. I wrote about this a long time ago:

We have a problem. People can't get from one area of town to a neighboring area because there is a river in between and no road. So let's build a bridge.

[Long discussion of how to plan to build a bridge in the real world]

Now, let's do it in software.

We're going to start by focusing on the problem to solve: get people from A to B. With software, the solution isn't necessarily as obvious as it is in the physical world. Maybe we need a bridge. But maybe we need a ferry. Or a helicopter service. Or maybe we should just move the two pieces of land closer together. Or freeze the river.

Customers speak in terms of solutions: I want a bridge. I want a bigger kitchen. But with software we know to be wary of this: unlike the physical world, the users of software often do not have a good intuitive understanding of what's possible. So while they speak in terms of functionality and solutions, it's our job to root out the real problem and come up with an appropriate solution - which we might also not have a good intuitive understanding of.

This article reminded me of this other classic: https://web.mnstate.edu/alm/humor/ThePlan.htm

It makes it clear that the main fault lies with managers. ;)

One of the most interesting things to me here re: the common question "why can't we build quickly anymore":

"They didn’t have design loopbacks because they had extremely experienced builders. The builders knew what they were doing. They had been building skyscrapers for between 30 and 40 years and they understood what they had to pay attention to and what was possible and what had to be designed in what order to eliminate the loopback. Now, all the computers in the world: they’re not going to substitute for deep experience. I propose that if they didn’t know what they were doing there’s no way: they would not have had the chance to hit that kind of number."

How many cities out there today have as many builders building skyscrapers at the same pace as they were then? Is there a way to get that speed back without the same sort of practice?

---

The workflow/independent stuff is also very interesting, but similar to the above question, it's tough to draw exact parallels to software. We've all seen big waterfall projects fail, and the "design floors on the fly independently" aspect has a lot of similarities with rapid iteration, etc, but software is somewhat different in that the labor and the design are the same - there isn't a "steel team" and a "concrete team" etc that can work completely independently, I don't think.

"Create the schedule and then figure out the project" is probably a super useful takeaway, though.

Anecdotally, my elderly father was an Architect for quite a long time - He claims the trend was (1) away from skilled labor and (2) towards contractors building only what is made explicit in drawings. I.e. details would be specified as "typical - see an example (only it's unusual)" and rely on the the best judgment of the contractor/labor to implement, while now work halts if there is any ambiguity. He thinks the old practce led to higher quality buildings more quickly, while the new practice is an inevitable consequence of legalism (everybody sues everybody when anything goes wrong) but more a consequence of less expert labor.

> Is there a way to get that speed back without the same sort of practice?

No.

Practice is the ONLY way to get good at anything. Doesn't matter what it is.

I'm not really understanding the distinction between a "plan" and a "workflow". It sounds like they had a plan but we are bending over backwards in TFA to call it something else because a plan is bad in some agile circles.

it's subtle, but "plan" (material resource planning, MRP) is essentially waterfall in this context, where you design first, then do work breakdown into a waterfall schedule. it suffers from cascading delays because of the bullwhip effect (among other things). it's project oriented (a 1-off, 1-time event).

in contrast, "workflow" is akin to kanban in this context. you start with constraints (in this case time and money) and then design the system to those constraints. mary, the speaker, mentions that they had 4 different, decoupled workflows, which helped them avoid those pesky cascading delays. workflows are process oriented (repeatable events), so steel construction, for example, was thought of as an separate repeatable (if varying) process (swimlanes, in kanban parlance) as they went up in height. kanban also focuses on realtime learning and adjustments as well as just-in-time inventory systems (important to steel being delivered on time, like using 2 different suppliers to make sure there were no delays).

this is the stuff you learn in operations class in business school (or some engineering programs), as did chris (the author of the article/blog), who went to ucla anderson.

Lack of a plan is what results in bullwhip effect; the bullwhip effect is caused by each silo iterating on its local knowledge...

> in contrast, "workflow" is akin to kanban in this context. you start with constraints (in this case time and money) and then design the system to those constraints. mary, the speaker, mentions that they had 4 different, decoupled workflows, which helped them avoid those pesky cascading delays. workflows are process oriented (repeatable events), so steel construction, for example, was thought of as an separate repeatable (if varying) process (swimlanes, in kanban parlance) as they went up in height. kanban also focuses on realtime learning and adjustments as well as just-in-time inventory systems (important to steel being delivered on time, like using 2 different suppliers to make sure there were no delays).

That sounds like a plan to me...

no, the bullwhip effect is caused by uncertainty across coupled tasks along the critical path, no matter the level of detail of your plan. it's a statistical phenomenon that you can mitigate with other measures, like critical chain. the empire state building example shows that they reduced coupling by creating 4 separate, independent workflows, mitigating the bullwhip effect by roughly a factor of 4.

Yes, the bullwhip effect is caused by uncertainty across coupled tasks. A plan that doesn't reduce and manage uncertainty is bad. Not having a plan means there is uncertainty even when all of the information is there to determine the answer. The empire state building had a plan for obtaining steel from foundries at the velocity they needed.

If one defines plan to mean "We schedule everything up front and then stick our fingers in our ears and say 'la la la la' when reality conflicts with our imagined schedule" then of course plans are bad. Similarly if one were to define agile as "a system that is incapable of delivering any feature that takes more than 2-4 weeks to develop" then agile would be bad too.

yes, another restatement of the distinction between 'plan' and 'workflow' as used in the talk.

I think what trips me up then is that "Plan" refers to a specific type of planning, I guess "MRP", but colloquially it would refer to anything that attempts to project how something will be done. Unfortunately I've had employers insist that planning in the colloquial sense was akin to waterfall and since we were agile it was verboten.

Obviously there were blueprints and solid estimates of the materials and labor required to build the thing. This was no Gaudí cathedral. But there was nothing telling someone when things would be at which stage of construction, just the knowledge that some parts needed to get done in the summer and the whole thing needed to be ready for occupancy on May 1.

I think the story of the submarine/Polaris missile was more interesting. They produced the plan and basically ignored it, and the PERT planning exercise has subsequently been cargo-culted for years.

yah, plan is an overloaded word, like most words. here it seems to boil down to the old adage of "good, fast, cheap. choose two."[0] if you set scope and budget (the "plan" version), then you have to be flexible on deadline. if you set deadline and budget (the "workflow" version), you have to be flexible on scope. for the empire state building, they designed the building (controlled scope) to fit the budget and deadline.

whether it's waterfall or agile shouldn't really matter. in agile, there is planning, but often it's workflow based (tracking flow via story points, or what not).

[0]: https://wikipedia.org/wiki/Project_management_triangle

The workflow is a function. You put in an input and get a consistent output within certain parameters

The plan is a procedural instruction list. It lacks consistency. It is whatever procedural set of things happened to have been written down. You wouldn't plan to reuse it like you would with the function because it only applies to that specific issue

The "four pacemakers" where "every one of these workflows was separate from the other workflows" could be read like an argument for microservices, doesn't it? I assume it's harder to make software as independent as say windows and floors, but I find it interesting to think about.

It’s more generally an argument for modularization, and for establishing well-defined interfaces between modules. Microservices is just one way this may get manifested.

A seminal paper is On the Criteria To Be Used in Decomposing Systems into Modules by David Parnas.

> If you have a stable system, then there is no use to specify a goal. You will get whatever the system will deliver. A goal beyond the capability of the system will not be reached.

    If you have not a stable system, then there is again no point in setting a goal. There is no way to know what the system will produce: it has no capability.

    As we have already remarked, management by numerical goal is an attempt to    manage without knowledge of what to do, and in fact is usually management by fear.

   Anyone may now understand the fallacy of “management by the numbers”.

Love this quote

the thing here that gets me c when compared to software is they had a schedule and they hit it early. This can happen in software, I think the appstore/iphone sdk is an example of having a date to hit and sticking to it, but it’s rare. I’d love to read an article about how the development of the iphone sdk and app store was managed, to see if it parallels these conclusions from the Empire State Building.

I was surprised that the alleged successful PERT origin was just theater for keeping politician money.

In fact this is my typical feeling with all Gantt charts.

Reply on news.ycombinator.com