Defense against the dark art of estimation bargaining (2014) • Hacker News Board

Re: Defense against the dark art of estimation bargaining (2014)

#71

Post by peterkelly » Mon, Aug 23, 2021, 7:14 AM UTC

ornornor wrote: post #67

peterkelly wrote: post #14

Here's my approach: "Look, there's two ways I can respond to this. I can be honest with you, and tell you the truth about how long I think it's going to take. You might not like the answer, but at least you will be in a position to make properly informed decisions about what to do, such as reducing the scope or adjusting the launch date. Alternatively, I can lie to you and give you an answer that will make you feel s…

What do you do if they choose “door number 2”, when the deadline is approaching and you’re pressured to work overtime while delivering subpar code that will be a major pain to modify and maintain for the rest of your time on that project, leading to even more pressure and overtime?

Quit (yes, seriously).

The extreme toll that burnout can take on your mental health simply isn't worth it. There are greener pastures out there and these days I only work with clients that prioritise quality over speed.

Re: Defense against the dark art of estimation bargaining (2014)

#72

Post by ornornor » Mon, Aug 23, 2021, 7:24 AM UTC

peterkelly wrote: post #71

ornornor wrote: post #67

Earlier quoted context omitted.

What do you do if they choose “door number 2”, when the deadline is approaching and you’re pressured to work overtime while delivering subpar code that will be a major pain to modify and maintain for the rest of your time on that project, leading to even more pressure and overtime?

Quit (yes, seriously). The extreme toll that burnout can take on your mental health simply isn't worth it. There are greener pastures out there and these days I only work with clients that prioritise quality over speed.

I’m genuinely interested because I’ve miserably failed at it so far.

When I inquire about the speed vs quality trade off in interviews or during discovery, the answer is always that quality is paramount. But a little later, when it comes down to the brass tacks, we’re asked to make the trade off and put speed over quality. Every time. Even when it was the company’s motto/yearly objective to “focus on quality”, even there, eventually speed was more important when pressed.

So I’m wondering: how do you find out whether quality is just lip service? It seems like a simple answer but over the last ten years I’ve always gotten it wrong and the project ended up being a pressure cooker with overtime to “fix” it.

Re: Defense against the dark art of estimation bargaining (2014)

#73

Post by CraigJPerry » Mon, Aug 23, 2021, 9:45 PM UTC

throw394024 wrote: post #68

CraigJPerry wrote: post #66

Earlier quoted context omitted.

Manipulation, passive aggression, telling you that your jobs on the line, … the chapter plays through a few realistic dialogues in the context of a developer providing an estimate the manager doesn’t like and the ways the manager tries to persuade the developer that they’ve guesstimated wrong. He rounds out the short chapter with an appeal to professionalism.

This is something I've never learned how to defend against. I've always tried to stay professional... but I'm a chronic under-estimator, and also find it difficult to say no, which is a recipe for disaster. Unfortunately people usually don't work like the team they purport to be (managers shielding their ICs, POs tracking down AC)-- they just see your willingness to work and exploit it for as much as you'll do, rathe…

We’re all chronic under-estimators by default so I wouldn’t beat yourself up over that one! The old planning fallacy is very well studied and documented. Humans are terrible at estimating by default unfortunately :-( but it’s not that hard to be conscientious about getting more accurate. For me, the secret is to just delegate to a tool that gives me estimates based on my past performance. The cost to me is nothing more than logging an estimate up front and recording what it ended up after the fact. Doing that for a few weeks rapidly steers you to breaking your work into small chunks because it’s too hard to make the recording work otherwise. Turns out small chunks of standalone useful outcomes are optimal anyway for 1001 other reasons.

As for saying no - one way could be to find a role model somewhere close around you, it should be easier to copy what they do if they’re in the same org structure and facing the same struggles. You can’t just assume to flick a switch and behave like them, everyone around you has an expectation of how you behave right now, so you have to be fairly active about signalling to people they should update their perceptions.