DEV Community

Cover image for Always over estimate effort
Andrea Canton
Andrea Canton

Posted on • Originally published at andreacanton.dev

 

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.

Top comments (15)

Collapse
 
jonrandy profile image
Jon Randy 🎖️

Better still, don't estimate - at all. I've learned over many years that it's almost always complete waste of time.

Collapse
 
andreacanton profile image
Andrea Canton

Totally agree, but most of the time you don't have the option.

Collapse
 
jonrandy profile image
Jon Randy 🎖️

That's what I used to think, but I started refusing to do it and never looked back.

Thread Thread
 
andreacanton profile image
Andrea Canton

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?

Thread Thread
 
jonrandy profile image
Jon Randy 🎖️ • Edited

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)

Collapse
 
kanekotic profile image
Alvaro • Edited

I am in that school of thought, actually is a well-established practice.
youtu.be/QVBlnCTu9Ms

Collapse
 
andreacanton profile image
Andrea Canton

I have literraly mentioned this in the last paragraph :)

Collapse
 
adamwdennis profile image
Adam Dennis

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.

Collapse
 
andreacanton profile image
Andrea Canton

SWAG estimate, ahahah!

I've twelve years of experience and still I feel I'm not good to estimate.

Collapse
 
codegaze profile image
Thanos Kolovos • Edited

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:

  • It is always good to mention, "From what we know so far...".
  • Give frequent updates if you are on track. Updates about the prediction validity or changes. Saying, "we need two more weeks", two days before release, is never good. Doing it early on saves a lot of complaints and time.
  • Estimate with ranges: 1-2 weeks, 4-6 weeks etc. This creates some buffer and gives space for unknowns. Some teams give best/worst case estimations.

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. :)

Collapse
 
lucrnz profile image
Lucie Dev

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.

Collapse
 
andreacanton profile image
Andrea Canton

Thank you for your comment. Tricky question: Can you really know when you are experienced enough? ;)

Collapse
 
lucrnz profile image
Lucie Dev

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

Collapse
 
michelsylvestre profile image
Michel Sylvestre

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

Collapse
 
andreacanton profile image
Andrea Canton

The original title of this article was "your estimate x 3" but maybe it was too cocky ;)

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.