by cangencer on 1/10/23, 4:36 PM with 53 comments
by cs702 on 1/10/23, 5:14 PM
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.
by numlocked on 1/10/23, 5:48 PM
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.
by gonzus on 1/10/23, 6:33 PM
by majormajor on 1/11/23, 1:25 AM
"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.
by peteradio on 1/10/23, 5:14 PM
by V__ on 1/10/23, 6:06 PM
by anm89 on 1/10/23, 10:11 PM
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”.
by twobitshifter on 1/10/23, 6:03 PM
by thuridas on 1/10/23, 9:14 PM
In fact this is my typical feeling with all Gantt charts.