←back to thread

"No, it's less effort than that"

(smartguess.is)
388 points replyifuagree | 1 comments | 21 Oct 23 04:43 UTC | HN request time: 0.325s | source
Show context
throwaway091ba ◴[21 Oct 23 11:26 UTC] No.37965914[source]▶
Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate, and why shorter is always better than longer. What they do instead, is try to protect their holy land of software development, and exacerbate the differences between engineers and "the others" - sarcasm and cynisism usually shine through at this time, and that's how you end up with unrealistic estimations.

I've been a developer, PO, manager, director, CTO, the whole thing. I'm still shocked by how most (not all, but most) developers are simply too disconnected from the reality that, yes, they do need to provide value, and yes, that value does have a time factor. Lucky are we as developers, that people actually ASK us how long it will take, and give us the opportunity to explain it, push back, and actually defend your estimates. The sad reality (at least from 90% of my career), is that developers are rarely able to actually engage in business-level conversations, and actually express their thoughts/ideas/concerns/proposals, in a way that it drives the conversation forward. In a way that helps PMs and managers actually see the complexities of the work, and engage in healthy cost/benefit discussions.

replies(16): >>37966013 #>>37966021 #>>37966029 #>>37966072 #>>37966099 #>>37966181 #>>37966182 #>>37966229 #>>37966278 #>>37966291 #>>37966455 #>>37966467 #>>37966730 #>>37967486 #>>37968163 #>>37968624 #
dlahoda ◴[21 Oct 23 11:46 UTC] No.37966013[source]▶
why shorter is always better than longer?
replies(3): >>37966049 #>>37966110 #>>37966179 #
sokoloff ◴[21 Oct 23 12:17 UTC] No.37966179[source]▶
Unless you’re in the business of “selling hours”, why wouldn’t having something valuable done more quickly (and thus at a lower expense) be better, all else being equal?

Sure, if you’re a contract dev shop who is marking up hours, then longer is better.

replies(2): >>37966347 #>>37969106 #
jeltz ◴[21 Oct 23 12:42 UTC] No.37966347[source]▶
From my experience this is simply not true because all else is never equal. Employee burnout, technical debt, risks taken due to rushing, people not doing the right tradeoffs, etc.
replies(2): >>37966527 #>>37967760 #
1. gnulinux ◴[21 Oct 23 15:47 UTC] No.37967760[source]▶
> Employee burnout, technical debt, risks taken due to rushing, people not doing the right tradeoffs, etc.

I've never seen a set of business people in a software company that cares about any of these things.

Some PMs will say they care about tech debt which excites me but of course in 6 months you'll see they actually cannot give a shit but just use it as a tool to lower the estimates. If X takes 5 days but they want 3 they'll tell you "let's just add some tech debt" to convince you to promise 3, but they don't actually ever intend to work on that tech debt.

When it comes to burnout, I've literally never seen any person who doesn't consider this the fault of the employee.

I've seen VP level people who did things that are so absolutely insane that it resulted the project to be late with 100% probably from 6 months before, then when the day of launch comes it is indeed late, fire alarms are pulled, tons of people give on-call attention to our project, we hack something. Then VP says "whoopies sorry about the fire alarm, will never happen again". Lmao next thing that happens is that this person is promoted to SVP and does it again and again. "Rushing" is a good thing, if anything. Business is all about creating an artificial sense of urgency that could be trivially averted, but it was chosen not to.

People not doing right trade offs. Well again, it's on you if you do the wrong trade off. People will point at you and say this decision was wrong. That I had so little information and time to make that decision is very brought up.