"No, it's less effort than that" • Hacker News Board

Re: "No, it's less effort than that"

#121

Post by orwin » Sat, Oct 21, 2023, 1:14 PM UTC

DiskoHexyl wrote: post #61

ejb999 wrote: post #11

Earlier quoted context omitted.

>>Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. Bingo, having just left a mega-corp this is the status-quo of a lot of projects I had visibility into - take a trivial task, estimate it at 8-13 story points (i.e. the whole 2 week sprint), have nobody question the estimates, complete the story in 1-2 days and then chill for the other 8-9 days left i…

Predictability is arguably more important than speed, especially when you have a lot of moving parts. When you have a developer that is slow, but constantly delivers on his estimates, you have a reliable IC that you can count on not failing to develop an API for some other team to integrate with. Fast and ambitious guys, who frequently fall behind their own estimates, are a pain in the ass to manage in large teams/co…

Fast and ambitious guys, who frequently fall behind their own estimates

I wasn't particularly fast, but I was this guy for a year. You're exactly right.

Re: "No, it's less effort than that"

#122

Post by dbalatero » Sat, Oct 21, 2023, 1:15 PM UTC

I think the biggest challenge I have is that people will immediately ask for estimates when the project is barely a paragraph description. On top of that, my feeling is always "it depends on how much tech debt is in the code after I look in there."

The only reasonable response I've had is "I need 1-2 days to both push you on solidifying these requirements, and stop & audit the codebase to look for any risks before starting".

Is there anything I could be doing better here?

Re: "No, it's less effort than that"

#123

Post by gregoriol » Sat, Oct 21, 2023, 1:18 PM UTC

This metaphor is wrong: meteorologists don't have any impact on the sunshine, whereas devs have direct impact on estimates.

In both cases, wrong estimates will generate problems for the stakeholders, but devs can make choices during the implementation that will influence the outcome and may in some ways mitigate the lower estimates, but meteorologists won't ever have any influence on the weather.

Re: "No, it's less effort than that"

#124

Post by crucialfelix » Sat, Oct 21, 2023, 1:23 PM UTC

dsego wrote: post #97

paulsutter wrote: post #23

The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule

Oh, but we need the full search functionality right now, yes there are only tens of entries now but in a few years there will be thousands. And the designer will design all the search flows based on our twenty page product requirements doc, and we will include engineering to write stories and estimate the works once it's all planned and prepared.

Also some designers throw in too many features because they want to fill space in the design.

Re: "No, it's less effort than that"

#125

Post by flagrant_taco » Sat, Oct 21, 2023, 1:26 PM UTC

bgribble wrote: post #91

masklinn wrote: post #72

Earlier quoted context omitted.

> The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions I think it's less simplification and more precision and completeness. Obviously if you have simpler requirements they more complete and precise, but the requirement might not actually be simplifiable. In which case what you want is better specification. "They…

As a developer I hate "precise" and "complete" requirements. Usually these extremely detailed roadmaps are just fairy tales. They indicate a management and product mindset that thinks you can pre-chew a developer's food for them and make things more predictable. In fact, what you are doing is tying the developer's hands and making it less possible for them to nimbly work around unforeseen obstacles or repurpose exist…

> As a developer I hate "precise" and "complete" requirements. Usually these extremely detailed roadmaps are just fairy tales.

Requirements and roadmaps are very different in my opinion. Requirements say what the product needs to do, scaling and/or response time targets, systems or needs to integrate with, etc. Roadmaps are either a high level plan for where the project goes in the future or a list of seemingly arbitrary deadlines.

Both have their place, but in my experience the right balance has been precise and complete specs with a high level, flexible roadmap.

Re: "No, it's less effort than that"

#126

Post by chiefalchemist » Sat, Oct 21, 2023, 1:28 PM UTC

I wish we could somehow get away from estimates where the expectation is precision and instead talk about a spectrum of possibilities (i.e., best case, worst case, and points in between). As the journey to the destination gets longer and more complex the range of possibilities increases. Why do we continue to pretend otherwise?

That aside, more accurate running scoring (if you will) would also help. Engineering is asked for an estimate but engineering knows that they don't have absolute complete control end to end of everything. Someone else somewhere along the line is going to cause delays, but the estimate stays fixed and engineering remains accountable. That's not helpful in the short term or long.

Re: "No, it's less effort than that"

#127

Post by makeitdouble » Sat, Oct 21, 2023, 1:29 PM UTC

nmstoker wrote: post #69

I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here. However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy. What's frustrating as a stakeholder is ludicrous estimates, which don't even s…

Ludricrous estimates are usually a symptom of other organizational quirks.

I'd compare it to the military's $435 hammer [0], from the outside you'd think it makes no sense, but that's the logical end of a series of processes that all somehwat made sense on their own.

A common issue I've seen is devs having to put their head on the chopping block when making estimates. After the second or third time they get seriously punished for blowing pat deadlines, they'll happily go with around 10 times their own estimate. But there's so many other incentives where going with a "done in 2h" estimate is just a bad decision.

[0] https://www.washingtonpost.com/blogs/wonkblog/post/the-penta...

Re: "No, it's less effort than that"

#128

Post by coldtea » Sat, Oct 21, 2023, 1:31 PM UTC

dbalatero wrote: post #122

I think the biggest challenge I have is that people will immediately ask for estimates when the project is barely a paragraph description. On top of that, my feeling is always "it depends on how much tech debt is in the code after I look in there." The only reasonable response I've had is "I need 1-2 days to both push you on solidifying these requirements, and stop & audit the codebase to look for any risks before st…

>Is there anything I could be doing better here?

Yes. Not give a fuck about the code debt and quality, and just rush out something that barely works. That will keep them satisfied.

Re: "No, it's less effort than that"

#129

Post by gemstones » Sat, Oct 21, 2023, 1:32 PM UTC

dbalatero wrote: post #122

I think the biggest challenge I have is that people will immediately ask for estimates when the project is barely a paragraph description. On top of that, my feeling is always "it depends on how much tech debt is in the code after I look in there." The only reasonable response I've had is "I need 1-2 days to both push you on solidifying these requirements, and stop & audit the codebase to look for any risks before st…

I have found success with having a session with the PM where the goal is not to have complete, perfect cards, but at least one ticket for every thing you can think you will need to do on the project.

So you’ll have a bunch of one liner cards, but at smaller fidelity, like

- Make a bulk create API endpoint - Migrate data from old to new table

Then, if there are 5 or more cards there, make your estimate

((number_of_cards / number_of_devs) * est_business_days_per_card) + est_pto_days

It will not be accurate - but it will leave the PM and their boss feeling like the estimate was thought out and reasonable at the time, and any necessary delays will go over easier (“we estimated assuming every card was about the same number of days, but these two cards were large outliers that took longer than expected.”)

Much like the normal sprint process, but without the need to keep a track of sprint velocity beyond a gut feel.

Re: "No, it's less effort than that"

#130

Post by hoosieree » Sat, Oct 21, 2023, 1:35 PM UTC

Typical action movie hacking scene:

    Leader: How long until you can hack the mainframe?
    Techie: The other hacker is really good; at least 2 hours.
    Leader: You have 1. Get it done!
    [commence flying around the 3d filesystem]

Whenever I watch a scene like this, I mentally add a voiceover for the techie:

    [Techie thinks]: My actual estimate was 20 minutes. I can probably get it done in about 50, then I need to fly in the 3d filesystem for 10 more minutes looking busy so Leader doesn't get any big ideas.