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

"No, it's less effort than that"

smartguess.is

Post reply on HN
Print view View original

151–160 of 388 posts

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

#151

Post by ResearchCode »

ejb999 wrote: post #11
zeroCalories wrote: post #5

Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. The only situation where this isn't a problem is with eager junior devs, and devs that have direct skin in the game, such as at startups or a department about to be cut for being unprofitable.

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

How about getting rid of the "stories", "points" and "sprints" altogether? Not only is the nomenclature abhorrent, the best software projects don't use enterprise agile methodology.

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

#152

Post by rrr_oh_man »

orwin wrote: post #113
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…

Don't ask for 30 minutes tasks unless you have to (it's breaking the prod or something), it's inefficient for everyone involved. I'm in a team with a lot of leeway. No one is counting my hours, no one external look at our productivity, but when we're needed, we don't have time to polish our code. When i have a '30 minute' task identified, I put it in our morning review, and ask if something adjacent should be done wh…

Any downsides to this approach, from your experience?

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

#153

Post by makeitdouble »

dahart wrote: post #135
makeitdouble wrote: post #127

Earlier quoted context omitted.

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…

Oh wow, I had no idea the story of the $600 hammer was still around. This has been a talking point for like 40 years now, and it was a different number when I was a little kid. Turns out the story had been debunked at least 13 years before the article you posted was written, and is 25 years old now. The military never paid hundreds of dollars for a hammer, someone just averaged a bunch of financial R&D overhead and t…

The averageing of the numbers is also the take of the article I checked, but to me it stays a good example of the phenomenon: that contract with no itemized prices and a high average price per item fits inside a procedure that probably isn't bad in itself, but gets turned into spicy headlines.

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

#154

Post by xorcist »

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…

Well, that's the nature of software.

If the requirements were actually precise and concrete, you could commit them to git and that would be the end of it.

The fact that they aren't is a sign of information deficit and this must be understood by all parties if we should have any chance of a productive outcome.

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

#155

Post by jvans »

The problem is not with estimates themselves, but on giving point estimates. A better way of saying something will take 2 weeks, is that there's a 80% chance this takes less than weeks, 15% chance it takes 2-4 weeks and 5% chance 4+. But people have a hard time wrestling with uncertainty so they'd rather a point estimate that's wrong but makes them feel like they understand the situation

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

#156

Post by steveBK123 »

The correct conversation is "what can we remove / what can I do / what can we re-prioritized / what else is in the way" to get some version of this ask earlier.

Simply bullying for a lower estimate, which is what I see 90% of the time is idiotic. Basically demanding to be negatively surprised later when the estimate slips rather than positive surprised when the dev is able to beat their initial estimate.

The first conversation requires empathy while the second conversation is a pure power flex. So it is unsurprising which we get more of.

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

#157

Post by zoomablemind »

Pushing for lower estimates is generally a sign of dysfunctional project manager.

This is when the PM does not have practical knowledge of existing obstacles to the project flow or the implications of external dependencies (intra team included).

This is a set up for throwing the team under the bus in case the schedule derails.

PM is supposed to harmonize the objectives and abilities, not manufacture the curves.

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

#158

Post by Veuxdo »

Aeolun wrote: post #73
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…

To some extend, but there’s tasks that I could do in 30m in a company with 15 employees that I have still not accomplished after 2 months in our 15k employee enterprise.

Linear scaling is more the exception than the rule, no? And it not just for "tech" either: it's unlikely you could learn the names of 15k employees in 2 months, for instance.

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

#159

Post by jalapenos »

It's more Machiavellian than that. What the middleman wants is a heads I win, tails you lose deal.

He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that.

So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - spoiling the whole play).

But when it inevitably takes much longer, he can point at the numbers the devs provided and say he was just communicating what they told him, so he's not responsible.

The only language these types understand is for requests for estimates to be "reviewed" to result in them always going up, to send a message.

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

#160

Post by maccard »

ResearchCode wrote: post #132
maccard wrote: post #118

Earlier quoted context omitted.

> If you don't think toxic managers and scrum masters If your managers and PM's are toxic you've already lost and no process is going to fix it. The only move is to change your team in that case. If everywhere you look you only see toxic managers though, maybe you're the problem.

The non-technical managers and agile coaches are the problem. That's why the best software projects don't have them. Linux kernel developers don't run story ticket velocity poker sprints.

An obsession with technical knowledge being superior to everything else is one of the most grating things about this community.

> The non-technical managers and agile coaches are the problem.

No, shitty managers are. In fact, most of the utterly useless managers and leaders I've had have been technical who just assumed that management, soft skills and leadership are "easy".

> That's why the best software projects don't have them.

There's no one definition of "best" software projects. And something being good software doesn't mean it serves a products needs.

> Linux kernel developers don't run story ticket velocity poker sprints.

The Linux kernel works because the project management knows their audience. The project is managed differently and ran differently. If I drop into an email thread talking about a large feature and say "I think that will take 2 days" people will disagree with that. That's all planning poker really is - once you've decided to do something, have a gut check on how much work it is.

Post reply on HN