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

"Tasks" in Intellij is great for this. You can hook it up to you project management tool (github, JIRA, trello etc) then checkout an issue and it will create a branch for that issue and track the time you spend on it.

Yep. I like the idea of an agency or internal team that does the following:

Come up with risk classes and complexity classes, with objective measure for what is or isn't in each class. ("Class X risk involves a library/technique/platform with we are not yet familiar.").

Measure time spent on all tasks.

Collect statistical distributions for each portion of the risk/complexity grid.

Use those distributions and monte carlo simulation to estimate future projects to an appropriate degree of confidence (e.g. 95%).

This probably means scheduling lots more time than you would have before, more than you will often need, use the rest for refactoring, training, completing unforeseen and therefore unestimated tasks (bug fixes?) maintaining the FOSS you are dependent on, etc.

Nitpicks, the term you want when you've been using "standard deviations" is either:

Distribution - general term for the shape of the relationship between probability and task length.

Triangular distribution or PERT - the specific shape of least/greatest/most likely you are using

Risk or Probability - the general concept that things are not definite and involve chance.

And where you are using "Total" for each item, you want "Mean" or "Median" depending which it is.

And I don't care to know the total mean or median time for scheduling, because the project will exceed that time 50% of the time (if it's the median, more if it's mean with long-tailed distributions) I would instead want some high quantile such that the chances of exceeding the schedule/budget are low (and which quantile I pick depends on my project, what's at risk if the schedule is exceeded).

I have good hearing and the music bothered me too. Way too loud.

I appreciate more attention being given to software estimates, but it seems like there's a lack of looking at the research in this area of software engineering. Most people have a single hocus-pocus equation that generates numbers they find convincing. Furthermore, it's often the case that these numbers are never changed over the life of the project.

That would be like predicting the weather with a single model, once, for the next three months. Of course that isn't going to work.

There are a few key points I think are often overlooked:

* Estimating is less about understanding time, and more about sizing a project and effort -- a study in software economics.

* Bottom-up estimates need to be based on historical performance. They should always be ranges and should include a notion of confidence. They should be democratically created if you're estimating for a team. You can do something simple (like Estimatr) or use a tool with a lot of data behind it (like Personal Software Process) - I do both.

* Top-down estimates should also be used. I often use COCOMO and COSYSMO, with monte carlo risk calculations (http://csse.usc.edu/tools/COCOMOII.php).

* The two approaches will give you two answers (both in ranges), with confidence intervals, which provides you a better sense of the size of the effort.

* Generating and publishing an estimate has a psychological effect on the team - consider that wisely (read Peopleware).

* Estimates are good for about two weeks, after that, they've become stale.

* You're not done with a project until you've recorded your performance data (for future bottom-up estimates).

* If a project is going to last three months or less, the research shows that nothing matters at all -- estimates, process, etc. -- do whatever keeps you/the team motivated.