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

Show HN: I built a free app to help devs create more accurate software estimates

estimatrapp.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: Show HN: I built a free app to help devs create more accurate software estimates

#21

Post by vmorgulis »

highCs wrote: post #18

I've a theory about that too. If you take a software development project, 80% of the stuff takes 20% of the time and 20% of stuff takes 80% of the time. Let's call the former noise and the latter the bottlenecks. A beginner estimates everything like the noise. So he's dramatically wrong. The novice though, estimates everything like bottlenecks. So he's dramatically wrong too. This is actually why, in the industry, th…

SLOCCount use the COCOMO method: http://www.dwheeler.com/sloccount/sloccount.html#cocomo

Re: Show HN: I built a free app to help devs create more accurate software estimates

#23

Post by elevensies »

The thing that helped me the most personally with my estimate accuracy is estimating times beforehand, and then tracking the actual time and evaluating the accuracy of my own estimates. This is partly to get out of the mindset of trying to explain why past estimates were over/under and focus on being more accurate in the future.

Re: Show HN: I built a free app to help devs create more accurate software estimates

#24

Post by joshmn »

davzie wrote: post #9
pbreit wrote: post #5

Here's one way: double the estimate and then cut the scope in half.

From experience, you're probably not wrong.

anddd get the best date you can. If you don't get it from stakeholders, it doesn't count. Get it from stakeholders.

Re: Show HN: I built a free app to help devs create more accurate software estimates

#25

Post by rpwilcox »

elevensies wrote: post #23

The thing that helped me the most personally with my estimate accuracy is estimating times beforehand, and then tracking the actual time and evaluating the accuracy of my own estimates. This is partly to get out of the mindset of trying to explain why past estimates were over/under and focus on being more accurate in the future.

Did it help? How often did you end up repeating the same task?

(Personally, I have this feeling that my tasks tend to be varied enough that 'number of times done' would almost always == 1, however, I don't have any actual data to back that assertion up. (And maybe you used this to hone in on the "true hour cost of a 2 story point task"???)

Re: Show HN: I built a free app to help devs create more accurate software estimates

#26

Post by syntiux »

highCs wrote: post #18

I've a theory about that too. If you take a software development project, 80% of the stuff takes 20% of the time and 20% of stuff takes 80% of the time. Let's call the former noise and the latter the bottlenecks. A beginner estimates everything like the noise. So he's dramatically wrong. The novice though, estimates everything like bottlenecks. So he's dramatically wrong too. This is actually why, in the industry, th…

This theory is called the Pareto principle and dates back to 1896. The wikipedia article is quite an interesting read: https://en.wikipedia.org/wiki/Pareto_principle

Re: Show HN: I built a free app to help devs create more accurate software estimates

#27

Post by [deleted] »

highCs wrote: post #18

I've a theory about that too. If you take a software development project, 80% of the stuff takes 20% of the time and 20% of stuff takes 80% of the time. Let's call the former noise and the latter the bottlenecks. A beginner estimates everything like the noise. So he's dramatically wrong. The novice though, estimates everything like bottlenecks. So he's dramatically wrong too. This is actually why, in the industry, th…

[deleted]

Re: Show HN: I built a free app to help devs create more accurate software estimates

#28

Post by elevensies »

rpwilcox wrote: post #25
elevensies wrote: post #23

The thing that helped me the most personally with my estimate accuracy is estimating times beforehand, and then tracking the actual time and evaluating the accuracy of my own estimates. This is partly to get out of the mindset of trying to explain why past estimates were over/under and focus on being more accurate in the future.

Did it help? How often did you end up repeating the same task? (Personally, I have this feeling that my tasks tend to be varied enough that 'number of times done' would almost always == 1, however, I don't have any actual data to back that assertion up. (And maybe you used this to hone in on the "true hour cost of a 2 story point task"???)

I am probably thinking here at a different level of granularity than you are, I would be talking about days to weeks here. I can't recall ever repeating the same task. It helped by letting me notice systematic errors and by helping me calibrate optimism / pessimism.

In my estimates I was focused too much on development time and not providing adequately for testing and deployment. On an existing project with the procedures already well in place it was fine, but for new or new-ish projects I was always under-estimating.

The other thing was calibrating my margin of safety. I now typically estimate at 2x the time that I think it will take to allow for unexpected issues and unrelated tasks that always pop up. That also works for me with the expectations of the people that I work with -- the estimates are used for planning and coordination and aren't effectively deadlines, but if I underestimate too often is causes coordination problems with the business people.

Re: Show HN: I built a free app to help devs create more accurate software estimates

#29

Post by hibikir »

ams6110 wrote: post #12
pbreit wrote: post #5

Here's one way: double the estimate and then cut the scope in half.

Or the other standby: take the dev estimate, double it, and increase the order of magnitude: Dev Estimate Quote ------------ ----------------- 2 hours 4 days 1 day 2 weeks etc...

There's only one problem with that rule: This is not done to dev estimates, but to the estimate of the next lower level of management. If your project has 5 levels of management before all participants are under one umbrella, team estimates in days will lead to a project taking years.

Claiming that the organization is flat is no cheat though: Create phantom managers so that ever 6 people have a manager, and those managers have managers, until the structure has a root. 300 programmers without managers would get 50 phantom first level managers, who have 9 phantom second level managers, 2 phantom third level managers, and a single phantom project managers. If an organization has more management layers than that, they will be even slower.

Re: Show HN: I built a free app to help devs create more accurate software estimates

#30

Post by BerislavLopac »

highCs wrote: post #18

I've a theory about that too. If you take a software development project, 80% of the stuff takes 20% of the time and 20% of stuff takes 80% of the time. Let's call the former noise and the latter the bottlenecks. A beginner estimates everything like the noise. So he's dramatically wrong. The novice though, estimates everything like bottlenecks. So he's dramatically wrong too. This is actually why, in the industry, th…

It's more like: The first 90% of the code takes the first 90% of the time, the remaining 10% of the code takes the other 90% of the time. [https://en.wikipedia.org/wiki/Ninety-ninety_rule]
Post reply on HN