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

61–70 of 388 posts

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

#61

Post by DiskoHexyl »

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…

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/companies.

Sure, with startups on the bleeding edge and with RnD it's different, but most of devs aren't doing that

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

#62

Post by egwor »

dlahoda wrote: post #55
throwaway091ba wrote: post #51

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

why shorter is always better than longer?

I came here to ask this too. I've had recent examples where the business has explicitly said the opposite (but we're long term greedy). I'm sure there are businesses on the verge of collapse where staying alive is the objective function. I'd be interested if there are other more common/healthy situations?

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

#63

Post by GoToRO »

throwaway091ba wrote: post #51

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

Well then bussiness people are also disconnected from reality. If a developer can write code and estimate and deliver in time for bussiness, then he is not an employee. He is a founder. What you want is people that deliver like a founder but that don't get any share of the profits. You want gullible people.

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

#64

Post by nonameiguess »

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.

Estimate high is the mathematically most valid thing to do in the face of uncertainty. This is more or less the fundamental theorem of finance. Expected rate of return increases with risk as compensation for the risk. Project planning should be following the same principle. If you're uncertain of traffic conditions, you leave earlier to be safe. If you're uncertain of future work unknowns, you estimate longer completion time to be safe.

If management is pushing for lower estimates, it's typically going some reason along the lines of:

- Someone higher up gave them a fixed budget or a fixed deadline and they can't exceed that.

- They're expecting market conditions to reward earlier delivery more than higher quality.

- They don't understand the problem domain.

- They do understand the problem domain but don't understand limiting factors like tech debt or organizational process hurdles the developers face that preven them from hitting timelines they would hit under ideal conditions.

If it's one of the latter two, they need to have a come to Jesus moment with themselves because you can't run a team if you don't understand what they do, how they do it, and what obstacles they face.

If it's one of the former two, great, communicate that, but then whoever is ultimately accepting or using your product needs to understand the basic release models that you can either get a complete set of well-defined features or you can get a specific release date but you can't get both, except by luck. And you need to have an organizational culture that isn't going to punish developers if they don't get lucky and meet only one of those goals.

Companies purchasing labor output don't get to violate the basic constraints of being a consumer. If you've got a fixed budget, fine, but you get what you pay for.

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

#65

Post by zeroCalories »

Buttons840 wrote: post #30
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. Developers have to push for higher estimates because management has an incentive to underestimate to make life easier. See what I did there? There's a fallacy in both statements: one side's actions are portrayed as greedy pursuit of "incentives" while the other side's actions are portrayed as a natur…

You're reading too much into the morallity. Furthermore how is it a fallacy?

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

#66

Post by b20000 »

throwaway091ba wrote: post #51

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

do developers own the business and will benefit the most of the upside?

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

#67

Post by dubcanada »

dlahoda wrote: post #55
throwaway091ba wrote: post #51

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

why shorter is always better than longer?

The OP is talking about business, so having something done in 2 days versus 4 days is always better. Ignoring everything else, less time is less money.

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

#68

Post by tyingq »

Dev teams have choices though. They can choose to use existing 3rd party code, services, etc, to accelerate development or not. They can choose some amount of non-functional requirements. They can choose the amount of "future proofing", abstraction, etc. And on and on...many choices that would drive timelines, trade speed for quality, longevity, maintainability, or cost, and so on.

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

#69

Post by nmstoker »

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 start with the work time, let alone end up with a realistic duration. This is particularly true (and frustrating) at the micro task level, an area I'm often requiring items that take at most 30 minute to complete and are usually things I could do in less time if only I had access... You get a weeks long estimate back, even when it's incurring a serious cost in production and falls in the drop everything category (which obviously one wants to avoid but does come up). I get that none of those 30 minute tasks will take 30 minute alone as there's testing and documentation to add but the more bs level the estimate, the more it damages the trust relationship.

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

#70

Post by WJW »

verve_rat wrote: post #58
throwaway091ba wrote: post #51

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

I agree with all the points you've made, but I would add that the PMs and managers and directors and whatnot are never that keen to help engineers out on this front. It is a rare person indeed that can do software development and think (and talk) in business terms. As a dev, being able to talk in business terms about the problems you face in creating software is really, really handy. But I can count on one hand the n…

In addition, any actual conversation wouldn't just require devs that can talk in business terms but also business people that can talk in development terms. Otherwise the only territory that can be usefully covered by both parties are the business requirements and the outcome will almost always be biased towards that.
Post reply on HN