Always over estimate effort
Developers solve problems no one have tried to solve before.
Trying to estimate how much time require to solve this problems is a guessing-game, is like gambling. Gambling is risky, so estimates should be superconservative.
Like gambling, you think you are good, because sometimes you get it right. But you are not, you are only lucky.
As a developer, even as a junior developer, you are responsible for the quality of the code, but our job is full of pitfalls. We have to check performance, maintainability, security and many other subjects.
If the persons who asked you the estimate say that is too much, remember they asked you, and if they needed a different answer they shouldn’t ask you in the first place. If they need it in less time you can discuss the timing, of course, but the responsibility of failure is not all on you, at least is shared.
Moreover, clients/PM/Product owner/etc. not always need all your work in short time, you don’t need to demonstrate always how quick you can be. Speed of delivery is not the only metric that matter.
Exaggerate estimate help you to keep calm and experiment various design pattern. If you think that they don’t give you time to do unit tests, refactor, clean tech debt, remember that are you that say the estimates.
So when you give yourself the chance to have some extra-time, you can really improve your codebase, and deliver very high quality code.
Thirty minutes can be enough to make significant improvements.
What is a better time to refactor a feature that anyway will be tested? You decide. You have the power to find time to improve the code.
Inspiration for this article, other than personal experience, is this talk by Allen Holub, where he says that doing estimates is stupid and you should not do it. I agree with him, but I’m not a CSO (Chief of Something Officer), I’m a senior developer of a company where I don’t have the option to don’t give estimates.
I hope this article start a discussion and help me and some of you to better manage this itchy argument.