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.
Top comments (15)
Better still, don't estimate - at all. I've learned over many years that it's almost always complete waste of time.
Totally agree, but most of the time you don't have the option.
That's what I used to think, but I started refusing to do it and never looked back.
If your manager ask you to do an estimate, or you work in a company where estimate have to be given. How can you refuse to do estimates?
By simply refusing, and explaining your reasoning. It's admittedly a little challenging at first, but it works out in the end (at least in my experience)
I am in that school of thought, actually is a well-established practice.
youtu.be/QVBlnCTu9Ms
I have literraly mentioned this in the last paragraph :)
As a developer, I hate giving estimates. As a leader/manager, I need estimates to set expectations. What a conundrum!
I think dev estimates are best understood when prefixed with the acronym โS.W.A.G.โ, ie โSWAG estimateโ โ or โScientifically Wild A** Guess estimateโ. This helps to set expectations that estimates arenโt contracts, theyโre more like โguesstimatesโโฆ devs sometimes get better at estimating over time, but not always, and thatโs okay imo.
SWAG estimate, ahahah!
I've twelve years of experience and still I feel I'm not good to estimate.
Estimations (I prefer Predictions as a word) are a problem when we violate the word's definition. Estimation is not a deadline or a promise. It's a prediction based on the data you have at that point. People, though, treat it like something written in stone.
Over-estimating may work, but it is a patch, not a solution. Based on my experience, the key is communication and here are some things that have worked:
Estimations are not easy, but it's a way to coordinate many things that don't have to do with Engineering work: product roadmap (a different conversation), Marketing collateral, Sales discussions etc. This requires some planning. Oh, and I don't know about you, but as an engineer, having a specific goal to deliver something has helped me focus on the things that matter most.
Disclaimer: What I mentioned can be achieved in a healthy environment without micromanagement. If people are having trouble with something that was "off" for hours or some days, you have a different problem.
I hope this helps. :)
My experience with estimations: At first, I used to try to impress people by saying I could complete tasks quickly, but that backfired a lot and made everything worse.
I would deliver projects late because of the unrealistic time-span I gave to myself.
Later, I realized that overestimating is the best approach. A lot of things can go wrong, especially if you are not experienced enough.
Additionally, the general time that goes into a project, such as asking for help, local testing, and the time your compiler takes to build the code to see changes, all add up to the estimation.
At best, if your estimation is too long, you might end up delivering before the date and making a better impression.
Thank you for your comment. Tricky question: Can you really know when you are experienced enough? ;)
Ahaha, well, I don't think we ever stop learning, to be honest !
But a baseline I would say is you really start understanding stuff probably at the 6 months mark, and then get to another level of understanding at the year mark.
Unfortunately not all contracts with clients are that long, so my final answer is: "I never really understand what I am doing" ๐
That was one of the first thing our teachers said many, many years ago in our early coding classes. Their rule of thumb was : "estimate then double it".
The original title of this article was "your estimate x 3" but maybe it was too cocky ;)