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

Ask HN: Why do software companies still insist on Estimation?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Ask HN: Why do software companies still insist on Estimation?

#11

Post by 3vidence »

I actually agree with this take, but I think the opposite can work. Create delivery dates based on runway / business priorities, re-evaluate what you think you can do in that amount of time. Every few weeks try to determine what you might need to cut to meet that date or see if the business can push back or delay that date.

I don't think starting from I think X feature will take Y days ever works. By contrast, we need to launch by Z date is technically a valid statement, it doesn't need to be estimated.

I think for this to work the business actually needs to be willing to admit that either more people need to be hired, features need to get cut or dates need to be pushed back.

Re: Ask HN: Why do software companies still insist on Estimation?

#12

Post by malux85 »

patrogizmo wrote: post #7

Let's talk about the reality of software development. Some projects are easy to estimate, especially in domains a developer has tackled before. As an example, consider a developer who has written five static pages who's asked to estimate how long it'll take them to write a sixth. Think of these projects as a well-defined path through the meadow to success. However, some projects are closer to crossing glacier for the…

> In their mind, that "I guess 3 months" estimate a developer gave quickly turns into "I can 100% deliver this to you fully tested, with all of the additions you added along the way in 3 months".

This is my biggest trigger, when a vague, hand-wavey estimate is turned into a signed guarantee, then the developer gets disciplined or treated as a problem creator when more detailed information comes in.

I found this was the problem with working at agencies - No matter how warm touchy feely they are, the fact is the agency is economically incentivised to burn out their developers (in the short term, which sadly, is the most frequently perceived time horizon).

This is why I only work at venture funded startups now with a preference for default-alive ones, yes it's a bit chaotic because resources are not infinite everywhere, but it's much better than working at an agency who are just middle-man reselling your time and trying to keep their margins up

Re: Ask HN: Why do software companies still insist on Estimation?

#13

Post by lesuorac »

I dunno, using previous projects as a similar baseline seems to work out very well for estimating within ~10% of future projects.

Although not all future projects are of a similar scope with similar people as a previous project but when it applies it seems to work well.

Re: Ask HN: Why do software companies still insist on Estimation?

#14

Post by 3vidence »

121789 wrote: post #10
superchroma wrote: post #3

Because you can't go to money people with "it'll take as long as it takes". It may be true, but that doesn't fit in Microsoft Project, and as long as there is another reputable group out there providing estimates, even junk ones, people will expect them.

well, it isn't really true. you should be able to estimate a project within an order of magnitude of time in the vast majority of instances. Think of 1 day 1 week 1 month 3 months 6 months 1 year 3 years if you had a random project, do you think you wouldn't be able to pick the most likely estimate and be within one level above or below? so "i have no idea, it'll take as long as it takes" is not really true.

Even this can be really deceiving, maybe core APIs to crucial libraries get removed. As a response maybe the team either needs to migrate to a new library, or rebuild the APIs from scratch.

A situation like this can turn a "X days" task into an "X months" task. I know it is not super realistic but it represents a type of situation.

Re: Ask HN: Why do software companies still insist on Estimation?

#15

Post by mcluck »

Accurately estimating work is possible and I have done it plenty of times. Precisely estimating work is nearly impossible. I'm of the opinion that everyone who has given up on estimates has some combination of not enough practice and inefficient communication of their estimates.

If I ask an average web developer if they can create a basic landing page in 3 months, they will always say 100% yes. Now shrink it to 1 month: 100%. 3 weeks: 90%. 1 week: 50%.

Now as the person paying for the work, you can make a choice. Do you plan to start advertising on the odds of a coin flip or do you wait until one of the 100% points?

Re: Ask HN: Why do software companies still insist on Estimation?

#16

Post by potamic »

When you hire a contractor to redo your kitchen, do you ask how long it may take?

When you order food online, do you expect to know when it will arrive?

When you go to your mechanic for a repair, do you want to know when you may get your car back?

When you go to a lawyer to verify a contract, do you need to know when they will be done?

Why should building a software solution be any different?

Re: Ask HN: Why do software companies still insist on Estimation?

#17

Post by yonixw »

potamic wrote: post #16

When you hire a contractor to redo your kitchen, do you ask how long it may take? When you order food online, do you expect to know when it will arrive? When you go to your mechanic for a repair, do you want to know when you may get your car back? When you go to a lawyer to verify a contract, do you need to know when they will be done? Why should building a software solution be any different?

> When you go to your mechanic for a repair, do you want to know when you may get your car back?

I want! However, for my old 2000 car, repairs exceeded the original estimate 80% of the time, forcing me to change my day-to-day plan. This could be a hint: good/new things breaks less, giving you false confidence when estimating for old/bad stuff.

Re: Ask HN: Why do software companies still insist on Estimation?

#18

Post by belfalas »

Why do software engineers insist on being paid when they never deliver any working software? Imagine a world in which programmers were only paid once their code hit production. My hypothesis is that estimation skills would improve at a geometric rate.

Said differently: good programmers are not afraid of making estimates. This classic article says it all better than I could: https://www.kitchensoap.com/2012/10/25/on-being-a-senior-eng...

From The Unwritten Laws of Engineering, quoted in the article:

Promises, schedules, and estimates are necessary and important instruments in a well-ordered business. Many engineers fail to realize this, or habitually try to dodge the irksome responsibility for making commitments. You must make promises based upon your own estimates for the part of the job for which you are responsible, together with estimates obtained from contributing departments for their parts. No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors."

Also from the article:

Avoiding responsibility for estimates is another way of saying, “I’m not ready to be relied upon for building critical pieces of infrastructure.”

Re: Ask HN: Why do software companies still insist on Estimation?

#19

Post by idonotexist911 »

Because they're not talking to only Developers but others who think in traditional project terms. Timelines, or at least tentative timelines. Or at least a range. Just something that someone ELSE can plan around. Like Marketing teams who need to know when something will likely work so they can do their own piece of work.

Re: Ask HN: Why do software companies still insist on Estimation?

#20

Post by chrsig »

Estimation can be a useful tool for a team to do to ensure that everyone has a shared understanding of a task.

Two drastically different estimations can highlight that there may be a lack of understanding or a high difference in skill / experience on the team. Knowing that allows empowers the team to break a task down smaller, make the task more clear, or spend some time educating team members.

I don't think those estimates should be shared outside the team.

Post reply on HN