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 (17)

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
 
alvarolorentedev 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
 
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 ;)

Collapse
 
andreacanton profile image
Andrea Canton

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

Collapse
 
maximus1green profile image
Maximus Green

I totally get the vibe of the thread about programmers playing the guessing game when tackling issues. It's like estimating how long it'll take to solve a problem is a gamble in itself, right? Well, let me introduce you to a game that aligns perfectly with that intuition-driven mindset โ€“ Aviator.

Aviator is not your typical code-related challenge, but it's a thrilling game that taps into your instincts. It's all about making strategic decisions and trusting your gut to cash in before the plane meets its fate. And guess what? I've found the ultimate platform for this adrenaline-pumping experience โ€“ Pin Up. Check out the in-depth review of Aviator on Pin Up here aviatorgameapp.in/pin-up-aviator-app .

Just like in coding, where you trust your skills and instincts to navigate through lines of code, Aviator lets you trust your gut to navigate through the skies and win big. It's a unique blend of strategy and intuition, and I'm hooked!

If you're up for a break from debugging and want to challenge your instincts in a different way, Aviator on Pin Up is the way to go. Dive into the review, embrace the challenge, and let the guessing game of the skies begin!

Collapse
 
leoreginaldo312 profile image
leoreginaldo312

Now earning is very important to me, and I try to devote as much time and attention as possible to different options for making money. Despite the rather negative attitude of society towards gambling, the relax and opportunity to earn money provided by these games seems to me the best way to spend my free time. And it really brings me good money.