What is Reddit's opinion of Software Estimation: Demystifying the Black Art (Developer Best Practices)?

From 3.5 billion Reddit comments

Estimation is an art. There are several techniques. You'd pick a technique depending on the project's size and other factors. Most devs have received no education in estimation, and just produce guesstimates. Using "expert judgement" should be the last resort. These estimates have little value and are often biased. If you go with this, at least provide best case, worst case and expected case.

Data based techniques are way better. For this you need historical data of your past projects: average time to complete a screen of size X, average time to create a web service with N methods, etc. That way you just estimate the number of screens/lines of code/whatever you need in your new project, and multiply by the average historical time. Of course there will be an error. But if you do this with every project, over time you will be able to calibrate your next estimates and reduce your estimation error.

There are several estimation techniques that are based on data:

• Decomposition and recomposition (by feature,by task, WBS, ...).
• Estimation by analogy (You know total LoC or time of similar past projects)
• Fuzzy logic (when you know LoC for features of sizes small, medium, large, etc)
• Components (when you know LoC or time per form, or per database table, or per retrofit service, etc)
• Story points (when you know LoC or time for a feature of N points)
• T-shirt sizing (when you know LoC or time for Small/Medium/Large code units, whatever the units might be).

If you have data, make sure it is data of Android projects, and using technologies similiar to what you are going to use (e.: don't estimate Compose UIs based on average time data for XML based UIs).

Estimations wil be better at the end of the project (cone of uncertainity).

For anyone interested, I recommend McConnell's often unknown little jewel on estimation: Software Estimation: Demystifying the Black Art

I would say the definitive book on this is Steve McConnell's book. He discusses everything, from the "cone of uncertainty" making early estimates be off by an order of magnitude, to explaining different methods of keeping yourself straight when coming up with estimates to managing expectations (commitment vs. estimate, buy spending more effort estimating you can't get the estimate lower, only more precise, etc.).

That said, I have found that trying to get estimates to be precise is rarely worth the effort. Mostly a ballpark estimate, multiplied by a correction factor derived from empirical data and setting limits where to enter cut-our-losses mode is quite enough.

It's certainly possible. There are many books about it too and here's a great example: http://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices-ebook/dp/B00JDMPOVQ/ref=sr_1_1?ie=UTF8&qid=1451153571&sr=8-1