11 Laws of Software Estimation for Complex Work
- Maarten Dalmijn tl;dr: (1) The work still takes the same amount of time regardless of the accuracy of your estimate. (2) No matter what you do, estimates can never be fully trusted. (3) Imposing estimates on others is a recipe for disaster. (4) Estimates become more reliable closer to the completion of the project. This is also when they are the least useful. (5) The more you worry about your estimates, the more certain you can be that you have bigger things you should be worrying about instead. And more.featured in #370
Yes, You Should Estimate Software Projects
- Gergely Orosz tl;dr: Businesses are date driven so should engineering teams be. It's a hard skill, and when estimates are wildly off, there's an opportunity to introspect and improve. Meeting estimates build trust. The key is communicating feature changes and tradeoffs with the business early on.featured in #159
Dear Startup: You Have No Idea How Much That Costs
- Kyle Prifogle tl;dr: The author puts forth the idea that engineers should ask management for deadlines when asked to build a feature, and explain what can be delivered within that timeframe. Not put the first foot forward by giving an estimate.featured in #158
Why Software Projects Take Longer Than You Think – A Statistical Model
- Erik Bernhardsson tl;dr: Developers estimate median completion time of projects well, but not the mean, which is problematic. The article illustrates why. This issue compounds with multiple estimates, and tasks with most uncertainty often dominate the mean time.featured in #137