[HN Gopher] The Tyranny of 'The Plan' (2013)
___________________________________________________________________
The Tyranny of 'The Plan' (2013)
Author : cangencer
Score : 86 points
Date : 2023-01-10 16:36 UTC (6 hours ago)
(HTM) web link (chrisgagne.com)
(TXT) w3m dump (chrisgagne.com)
| numlocked wrote:
| 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.
| cs702 wrote:
| 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]
|
| 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.
| projektfu wrote:
| 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.
| cm2012 wrote:
| I strongly suspect that the excellent planning behind Empire
| State led to less deaths than equivalent towers from that time.
| clairity wrote:
| BLS says that roughly 5000 people die in construction accidents
| annually. those deaths are certainly tragic, but not
| disproportional.
| yamtaddle wrote:
| 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.
| nerdponx wrote:
| 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?
| ElevenLathe wrote:
| 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.
| mrguyorama wrote:
| 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_
| yamtaddle wrote:
| > 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).
| axus wrote:
| 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.
| majormajor wrote:
| 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.
| eternityforest wrote:
| 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.
| atoav wrote:
| "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.
| newsclues wrote:
| > 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).
| ciscoriordan wrote:
| 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.
| newsclues wrote:
| Louis Slotin was a scientific hero for myself as a young
| person.
| cs702 wrote:
| Good point! I added " -- expect in extreme circumstances,
| like war" to the last paragraph. Thank you.
| nerdponx wrote:
| 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.
| peteradio wrote:
| 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.
| clairity wrote:
| 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.
| peteradio wrote:
| 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.
| projektfu wrote:
| Obviously there were blueprints and solid estimates of the
| materials and labor required to build the thing. This was
| no Gaudi 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.
| clairity wrote:
| 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
| anm89 wrote:
| 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
| twobitshifter wrote:
| 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.
| V__ wrote:
| 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.
| layer8 wrote:
| 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.
| anm89 wrote:
| > 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
| thuridas wrote:
| 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.
| gonzus wrote:
| This article reminded me of this other classic:
| https://web.mnstate.edu/alm/humor/ThePlan.htm
| layer8 wrote:
| It makes it clear that the main fault lies with managers. ;)
| [deleted]
| chitowneats wrote:
| [flagged]
| QuiDortDine wrote:
| 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".
| chitowneats wrote:
| I value stability in software development. I value self-
| regulation. I do not need someone on my team to encourage
| these. I need software engineers who have these values.
| "Gurus" like this person are an unnecessary cost, if not an
| outright scam.
| xyzelement wrote:
| 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.
___________________________________________________________________
(page generated 2023-01-10 23:00 UTC)