Re:Project delays: why good software estimates are impossible
by ktRolster on Saturday July 23, 2016 @11:55AM
(#12149830)
it's extremely hard to account for bugs that aren't discovered until later.
Pad your estimates, because you are typically going to have similar bugs (for similar projects), and you can account for those unknowns probablistically. You don't know the exact bugs that will be found, but you've already predicted that some will be found, so include that in your estimate.
Re:Project delays: why good software estimates are impossible
by mentat on Saturday July 23, 2016 @11:53AM
(#12149816)
That why you use procedures that find bugs early. This has been solve (in various ways) since the 70s yet people are still writing about how it's "not possible".
Re:Project delays: why good software estimates are impossible
by perspectivep on Saturday July 23, 2016 @11:56AM
(#12149836)
We do. Unit tests, integration tests, manual smoke tests, code reviews of every commit, design reviews, self hosting...
Sometimes your test matrix is too big. But I agree: sometimes you have to move slower in order to go faster overall and have better estimates. Estimates have to take into account testing and regression testing, which most people don't so it can make you look slow if you start doing that.
Re:Project delays: why good software estimates are impossible
by ktRolster on Saturday July 23, 2016 @12:02PM
(#12149867)
If you're having trouble, this book can help you: https://www.amazon.com/Zero-Bugs-Program-Faster-Thompson/dp/...
I usually have a pretty accurate estimate for small tasks but never go back and add the time spent on fixing recessions caused by that task. Or the time spent on extra smoke testing due to missing automation.