[perspectivep]

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.

[ktRolster]

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.

[mentat]

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".

[perspectivep]

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.

[ktRolster]

If you're having trouble, this book can help you: https://www.amazon.com/Zero-Bugs-Program-Faster-Thompson/dp/...

[jonex]

You should probably mention that it's your own book you are plugging here.

[ktRolster]

ok, next time I will. Edit window has ended.