[HN Gopher] The carefulness knob
___________________________________________________________________
The carefulness knob
Author : azhenley
Score : 80 points
Date : 2024-10-30 15:58 UTC (1 days ago)
(HTM) web link (surfingcomplexity.blog)
(TXT) w3m dump (surfingcomplexity.blog)
| AnotherGoodName wrote:
| Fwiw in a real world scenario it'd be more helpful to hear "the
| timeline has risks" alongside a statement of a concrete process
| you might not be doing given that timeline. Everyone already
| knows about diminishing returns, we don't need a lesson on that.
| Swizec wrote:
| My favorite tool when defining project timelines: What are we
| _not_ doing?
|
| There's an infinite number of nice-to-haves. A nice good
| deadline makes it super easy to clarify what you actually
| _need_ vs what you only want.
| TylerE wrote:
| and you'd be amazed when you start really having these
| discussions with the client how often stuff ends up not only
| not being needed, but often going right past 'nice to have'
| and right to 'lets not'. The problem is often the initial
| problem being WAY overspecified in ways that don't ACTUALLY
| matter but generate tons of extra work.
| whstl wrote:
| Yeah, to me this kind of thing is much better than the
| carefulness knob.
|
| Delaying or just not doing _certain_ features that have low
| ROI can drastically shorten the development time without
| really affecting quality.
|
| This is something that as an industry we seem to have
| unlearned. Sure, it still exists in the startup space, with
| MVPs, but elsewhere it's very difficult. In the last 20
| years I feel like engineers have been pushed more and more
| away from the client, and very often you just get
| "overspecified everything" from non-technical Product
| Managers and have to sacrifice in quality instead.
| TylerE wrote:
| If everyone actually knew this stuff, this entire class of
| problem would cease to exist. Given that it has not...
| hinkley wrote:
| I've been in this industry a long time. I've read Lying with
| Statistics, and a bunch of Tufte. I don't think it would be too
| much hyperbole to say I've spent almost a half a year of
| cumulative professional time (2-3 hours a month) arguing with
| people about bad graphs. And it's always about the same half
| dozen things or variants on them.
|
| The starting slope of the line in your carefulness graph has no
| slope. Which means you're basically telling X that we can turn
| carefulness to 6 with no real change in delivery date. Are you
| sure that's the message you're trying to send?
|
| Managers go through the five stages of grief every time they ask
| for a pony and you counteroffer with a donkey. And the charts
| often offer them a pony instead of a donkey. Doing the denial,
| anger and bargaining in a room full of people becomes toxic, over
| time. It's a self goal but bouncing it off the other team's head.
| Don't do that.
| debacle wrote:
| Maybe we need to start with Zeno. Doing anything at all is
| relatively impossible.
| kmoser wrote:
| > The starting slope of the line in your carefulness graph has
| no slope. Which means you're basically telling X that we can
| turn carefulness to 6 with no real change in delivery date.
|
| This strikes me as a pedantic argument, since the graph was
| clearly drawn by hand and is meant to illustrate an upward
| curving line. Now, maybe there's essentially no clear
| difference between 5 and 5.1, but when you extrapolate out to
| where 6 _would be_ (about 65 pixels to the right of 5, if I can
| be pedantic for a moment), there actually _is_ a difference.
| hinkley wrote:
| This is a conversation about human behavior, not pixels.
|
| A flat line will lead to bargaining, as I said. Don't paint
| yourself into uncomfortable conversations.
|
| If you don't want the wolf in the barn don't open the door.
| hyperpape wrote:
| And I've done high school calculus. It's a picture of a
| parabola, the derivative is very small near the minimum, and it
| can look kinda flat if the picture isn't perfectly drawn.
|
| Principles of Product Development makes the point that a lot of
| real world tradeoffs in your development process are U-shaped
| curves, which implies that you will have very small costs for
| missing the optimum by a little. A single decision that you get
| wrong by a lot is likely to dominate those small misses.
| hinkley wrote:
| It's a picture of a parabola if someone put the y axis at the
| dotted line not the origin. If you want to bargain with
| people - and this fictional conversation is a negotiation -
| then don't anchor the people on bad values.
| throwway120385 wrote:
| A more sensible way to present the idea is to put the turning
| point of the parabola at the origin of the graph and then
| show that 5 is somewhere on the line of super-linearly
| increasing schedule risk.
| 123pie123 wrote:
| It generally comes down to the age old question, pick two out of:
| Quality, Speed or Cost
| terlisimo wrote:
| A personal anecdote:
|
| One of my guys made a mistake while deploying some config changes
| to Production and caused a short outage for a Client.
|
| There's a post-incident meeting and the client asks "what are we
| going to do to prevent this from happening in the future?" -
| probably wanting to tick some meeting boxes.
|
| My response: "Nothing. We're not going to do anything."
|
| The entire room (incl. my side) looks at me. What do I mean,
| "Nothing?!?".
|
| I said something like "Look, people make mistakes. This is the
| first time that this kind of mistake had happened. I could tell
| people to double-check everything, but then everything will be
| done twice as slowly. Inventing new policies based on a one-off
| like this feels like an overreaction to me. For now I'd prefer to
| close this one as human error - wontfix. If we see a pattern of
| mistakes being made then we can talk about taking steps to
| prevent them."
|
| In the end the conceded that yeah, the outage wasn't so bad and
| what I said made sense. Felt a bit proud for pushing back :)
| debacle wrote:
| Good manager, have a cookie.
| tpoacher wrote:
| Good, but I would have preferred a comment about 'process
| gates' somewhere in there [0]. I.e. rather than say "it's
| probably nothing let's not do anything" only to avoid the
| extreme "let's double check everything from now on for all
| eternity", I would have preferred a "Let's add this temporary
| process to check if something is actually wrong, but make sure
| it has a clear review time and a clear path to being removed,
| so that the double-checking doesn't become eternal without
| obvious benefit".
|
| [0] https://news.ycombinator.com/item?id=33229338
| tqi wrote:
| [preface that this response is obviously operating on very
| limited context]
|
| "Wanting to tick some meeting boxes" feels a bit ungenerous.
| Ideally, a production outage shouldn't be a single mistake
| away, and it seems reasonable to suggest adding additional
| safeguards to prevent that from happening again[1]. Generally,
| I don't think you need to wait until after multiple incidents
| to identify and address potential classes of problems.
|
| While it is good and admirable to stand up for your team, I
| think that creating a safety net that allows your team to make
| mistakes is just as important.
|
| [1] https://en.wikipedia.org/wiki/Swiss_cheese_model
| terlisimo wrote:
| I agree.
|
| I didn't want to add a wall of text for context :) And that
| was the only time I've said something like that to a client.
| I was not being confrontational, just telling them how it is.
|
| I suppose my point was that there's a cost associated with
| increasing reliability, sometimes it's just not worth paying
| it. And that people will usually appreciate candor rather
| than vague promises or hand-wavy explanations.
| AnimalMuppet wrote:
| Yeah. Policies, procedures, and controls have _costs_. They can
| save costs, but they also have their own costs. Some pay for
| themselves; some don 't. The ones that don't, _don 't create
| those procedures and controls_.
| ErrantX wrote:
| Correct.
|
| Corollary is that Risk Management is a specialist field. The
| least risky thing to do is always to close down the business
| (can't cause an incident if you have no customers).
|
| Engineers and product folk, in particular, I find struggle to
| understand Risk Management.
|
| When juniors ask me what technical skill I think they should
| learn next my answers is always; Risk Management.
|
| (Heavily recommended reading: "Risk, the science and politics
| of fear")
| klabb3 wrote:
| It's not the right approach. Structural engineers shouldn't let
| management fiddle with their safety standards to increase speed.
| They will still blame you when things fail. In software, you
| can't just throw in yolo projects with much lower "carefulness"
| than the rest of the product, everything has maintenance. The TL
| in this case needs to establish a certain set of standards and
| practices. That's not a choice you give away to another team on a
| per-feature basis.
|
| It's also a ridiculous low bar for _engineering_ managers to not
| even understand the most fundamental of tradeoffs in software. Of
| course they want things done faster, but then they can go
| escalate to the common boss /director and argue about
| _prioritization_ against other things on the agenda. Not just
| "work faster". Then they can go manage those whose work output is
| proportional to stress, not programmers.
| atoav wrote:
| Which is why liability is needed.
| thrw42A8N wrote:
| Management decides whether they build a cheap wooden building,
| a brick one, or a steel skyscraper. These all have different
| risk profiles.
|
| Safety is a business/management decision, even in structural
| engineering. A pedestrian bridge could be constructed to
| support tanks and withstand nuclear explosions, but why. Many
| engineered structures are actually extremely dangerous - for
| example mountain climbing trails.
|
| Also yes, you have many opportunities to just YOLO without
| significant consequences in software. A hackathon is a good
| example - I love them, always great to see the incredible
| projects at the end. The last one I visited was sponsored by a
| corporation and they straight up incorporated a startup next
| day with the winning team.
| karaterobot wrote:
| _LT is a member of the leadership team._
|
| LT: Get it done quick, and don't break anything either, or else
| we're all out of a job.
|
| EM: Got it, yes sir, good idea!
|
| [EM surreptitiously turns the 'panic' dial to 10, which reduces a
| corresponding 'illusion of agency' dial down to 'normal']
| PlunderBunny wrote:
| I like the idea of having an actual 'carefulness knob' prop and
| making the manager asking for faster delivery/more checks
| actually turn the knob themselves, to emphasise that they're the
| one responsible for the decision.
| nine_zeros wrote:
| Yep. The best way to pushback is to ask your manager, "We'll do
| it fast since you are asking for it. What is the plan for
| contingencies in case things break?"
___________________________________________________________________
(page generated 2024-10-31 23:00 UTC)