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.<p>My only reservation is that the OP fails to mention that some workers <i>died</i> 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]<p>See also: <a href="https://patrickcollison.com/fast" rel="nofollow">https://patrickcollison.com/fast</a> .<p>--<p>[a] <a href="https://en.wikipedia.org/wiki/Empire_State_Building#Construction" rel="nofollow">https://en.wikipedia.org/wiki/Empire_State_Building#Construc...</a><p>[b] In some parts of the world, projects are routinely finished faster at the expense of human lives. For example, according to <a href="https://www.theguardian.com/football/2022/nov/27/qatar-deaths-how-many-migrant-workers-died-world-cup-number-toll" rel="nofollow">https://www.theguardian.com/football/2022/nov/27/qatar-death...</a> , 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.<p>--<p>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.
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:<p>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.<p>[Long discussion of how to plan to build a bridge in the real world]<p>Now, let's do it in software.<p>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.<p>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: <a href="https://web.mnstate.edu/alm/humor/ThePlan.htm" rel="nofollow">https://web.mnstate.edu/alm/humor/ThePlan.htm</a>
One of the most interesting things to me here re: the common question "why can't we build quickly anymore":<p>"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."<p>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?<p>---<p>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.<p>"Create the schedule and then figure out the project" is probably a super useful takeaway, though.
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.
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.
> 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.<p><pre><code> 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”.
</code></pre>
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.<p>In fact this is my typical feeling with all Gantt charts.