4 ms·
Even if you get better at estimating tasks, it's extremely hard to account for bugs that aren't discovered until later. I usually have a pretty accurate estima
by perspectivep 10y ago
Even if you get better at estimating tasks, it's extremely hard to account for bugs that aren't discovered until later.
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.
- mentat 10y agoThat 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".
- perspectivep 10y agoWe 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.
- ktRolster 10y agoIf you're having trouble, this book can help you: https://www.amazon.com/Zero-Bugs-Program-Faster-Thompson/dp/0996193308 https://www.amazon.com/Zero-Bugs-Program-Faster-Thompson/dp/...
- ktRolster 10y agoit'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.