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]
[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).
"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.
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
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.
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.
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.
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”.
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.
Do you really feel like this is a real contribution to the conversation? Agile coaches help stabilize software development, and meditation teachers teach a valuable self-regulation skill. You not wanting or valuing something doesn't make it "snake oil".
I am iffy on agile (I feel like it is a codification of common sense, but people who need common sense codified are going to fuck up anyway) but I think meditation has proven universally valuable with no controversy.
A hedge fund I used to work at would encourage and pay for Transcendental Meditation training ($1000 I believe) because the correlation between meditation and better decisions making/collaboration was so blatant.
cs702|3 years ago
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]
See also: https://patrickcollison.com/fast .
--
[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.
yamtaddle|3 years ago
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).
atoav|3 years ago
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.
projektfu|3 years ago
[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.
seventhtiger|3 years ago
"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.
kragen|3 years ago
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
newsclues|3 years ago
Depends. I think the Manhattan Project killed more people (not including using the bombs in combat).
cm2012|3 years ago
clairity|3 years ago
samstave|3 years ago
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...
imgabe|3 years ago
nerdponx|3 years ago
numlocked|3 years 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.
gonzus|3 years ago
layer8|3 years ago
majormajor|3 years ago
"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.
xkcd-sucks|3 years ago
slotrans|3 years ago
No.
Practice is the ONLY way to get good at anything. Doesn't matter what it is.
peteradio|3 years ago
clairity|3 years ago
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.
anm89|3 years ago
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
unknown|3 years ago
[deleted]
V__|3 years ago
layer8|3 years ago
A seminal paper is On the Criteria To Be Used in Decomposing Systems into Modules by David Parnas.
anm89|3 years ago
twobitshifter|3 years ago
thuridas|3 years ago
In fact this is my typical feeling with all Gantt charts.
chitowneats|3 years ago
[deleted]
QuiDortDine|3 years ago
xyzelement|3 years ago
A hedge fund I used to work at would encourage and pay for Transcendental Meditation training ($1000 I believe) because the correlation between meditation and better decisions making/collaboration was so blatant.