Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tyranny of ‘The Plan' (2013)

chrisgagne.com

Post reply on HN
Print view View original

31–40 of 56 posts

Re: The Tyranny of ‘The Plan' (2013)

#31

Post by chitowneats »

QuiDortDine wrote: post #28
chitowneats wrote: post #20

[flagged]

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 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.

Re: The Tyranny of ‘The Plan' (2013)

#33

Post by mrguyorama »

nerdponx wrote: post #24
yamtaddle wrote: post #16

Earlier quoted context omitted.

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?

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

Re: The Tyranny of ‘The Plan' (2013)

#34

Post by anm89 »

> 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

Re: The Tyranny of ‘The Plan' (2013)

#35

Post by anm89 »

peteradio wrote: post #3

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 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

Re: The Tyranny of ‘The Plan' (2013)

#36

Post by atoav »

cs702 wrote: post #2

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 buil…

"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.

Re: The Tyranny of ‘The Plan' (2013)

#38

Post by layer8 »

V__ wrote: post #13

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.

Re: The Tyranny of ‘The Plan' (2013)

#39

Post by hunter-gatherer »

axus wrote: post #25
yamtaddle wrote: post #5

Earlier quoted context omitted.

> 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).

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.

Re: The Tyranny of ‘The Plan' (2013)

#40

Post by aidenn0 »

clairity wrote: post #8
peteradio wrote: post #3

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 mone…

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...

Post reply on HN