The 10x striver: A short story, about you.
Chapter 1 - Planning
You're a programmer, you're in the middle of sprint planning with your team. A new feature has been requested by a customer and you've been given the go-ahead. The feature seems pretty simple: add a nice popup to tell the user they're being a silly bugger putting a string in the age picker. You think of the app, you know there are places popups have been used, you've not seen the code, but you know its there.
You take a momentary glance at the other developers who are watching expectantly, waiting for the question. "So, how long do you think this will take you?". This is your moment, this is your time to shine, nothing can stop you, you're a 10x. You let out a loud sigh to ensure you have everyone's undivided attention. "Half a day".
Chapter 2 - Half a day
Half a day, half a day, half a day. This is now your mantra.
It has been a week since you uttered those words. Every morning you have had to drag yourself to your morning stand up and repeat, "I'm still working on...". You make up excuses about the code in the area being hard to understand, unreadable or an insufficient amount of tests. You wish you could rewind time and give a more reasonable estimation.
It is not YOUR fault
So many of us have been there, we've completely underestimated a task we thought was trivial and it took far longer than we could ever have expected. This is not your fault, this is something humans are inherently bad at.
It is fortune-telling.
This is commonly known as the planning fallacy which is a phenomenon where predictions on how much time a particular task will take to complete are exceedingly optimistic, often disregarding the knowledge of prior, similar tasks.
The planning fallacy only occurs when planning for our own tasks, interestingly, us humans take a much more pessimistic approach when estimating for other people.
And also, the more knowledge you have around a certain area the smaller that optimism bias gets. So that explains why the senior developer who has been working on the app since the beginning was shaking his head at you when you said half a day.
We want to impress
Everyone wants to be decent at what they do, everyone wants to be an asset to the team. You want to be the developer who can get sh*t done.
And in our want to impress we only increase the amount we underestimate tasks (As shown by the brilliant story above🤣). Unfortunately, as programmers, a lot of our sprint-planning meetings are done in groups so that need to impress is often multiplied.
Pressure from above
Often it is not just the need to impress which can skew our estimations, it could also come from your team leader, or your project manager, or the CEO of the bloody company.
We all love Elon Musk, but blimey does he make some crazy deadlines. I can only imagine the pressure the engineers must feel working for him!
It's not all bad (Parkinson's Law)
Parkinson's law is the notion that work expands so as to fill the time available for its completion. So basically, you know that time when you had to finish a school assignment in 2 days and you managed to get your shit together and get it done? That's Parkinson's Law.
You underestimating the time it's going to take you to implement a feature may make you work harder at hitting the deadline, but that's only if you place a high degree of importance on getting it done. If you aren't all that bothered if your work takes longer than estimated then Parkinsons Law probably won't have much of an effect.
This is likely why Elon Musk makes crazy deadlines for his engineers, putting them in a perpetual state of Parkinsons Law forcing them to work their asses off.
So how do I get better at estimating?
In Software Estimation by Steve McConnell he recommends:
- Breaking the problem into sub-problems or sub-tasks
- Estimate using ranges rather than giving an explicit date (This depends on how your company estimates)
- Find similar completed tasks, so how long it took you to implement a feature in the same area. Essentially use your prior knowledge.
- Understand your margins - if you're estimating something completely new you might need to take a 100% or even 400% factor.
- Communicate with the appropriate people about your estimation as you refine it.
Finally
I wrote this blog because as I said, humans are inherently bad at estimating, but I myself am probably even worse than the average human. Even just this week I've underestimated a ticket I thought would take me a couple hours, probably prompting me to write this blog.
The moral of the story:
if you're shit at estimating, don't worry about it, we all are.
I'd love to hear your thoughts and or stories of times you've underestimated a task or even your own tips for making estimations. Equally, I'd like to hear from the 10x developers who estimate bang on every time 😄.
This blog is sponsored by Code Canvases
Make your room come alive with the coolest programming/coding canvases on the market. codecanvases.com is the number 1 seller for programming prints with 100% exclusively designed canvases. Get them now whilst they're 20% off!!
](https://res.cloudinary.com/practicaldev/image/fetch/s--qTjLHF_e--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cdn.shopify.com/s/files/1/0311/0151/7955/products/jqbr8djyof6ktl8qopmkpvy4_480x480.png%3Fv%3D1585483987)
Latest comments (53)
I think we also often fail to take into account "coordination overhead" - e.g. when my task depends partially on understanding or agreeing an approach taken by someone else working on another task.. or liaison back and forth with a client or designer. Sometimes these chats and slack convos end up taking a decent chunk of time and I think we're pretty bad at factoring it in!
Completely, that's something that didn't even cross my mind! Thank you Suzanne.
Alternative:
...
The project is actually delivered in 4 months.
Moral of the story.
Great SELLER!!!
Spot on!
One rule I use is, whenever I give a hardcoded estimate, for example half-day work, I double that to be sure, so it becomes a days work.
This is a solid topic. Thanks for writing it! 🙌🏻
I've created a 3 point estimate Excel.
When I need to estimate effort for a development project I use it to get a more realistic estimation.
It even has a risk indicator that adds an extra percentage depending on the risk level, etc.
It basically allows me to write down my best case, realistic, and worst case estimation for a (sub)task.
This is less overdone than a X times multiplier but it doesn't overcome the fact that experience/historical metrics, and the need for objective estimations still remain very important.
It’s important, that when you need to fix estimates in a team, most probably the root cause lies in management. Estimates are estimates, but this is hard to understand for managers. So, the most important part is to acknowledge that even if estimates get better, the work won’t be done faster.
If that step has reached, based on my experience it works pretty good to use points and fixed length iterations. Once team (and it should alway estimate the whole team) has a good common sense on how many points for a comparable task, you just change the meaning of what a point is, based on how many points have been successfully delivered in the iteration. You dont‘t try to improve the estimations itself.
There will still be times where you will still need a week longer than planned. But that’s the way it is.
Ah, and breaking something up in subtasks can help, but it’s not worth to do that upfront if it’s not clear that the task will be done at all. In that case, simple team complexity estimation is sufficient.
I particularly like the part about even if estimates get better, the work won't be done faster, I'll have to use that next time when I'm trying to blame the bad code for me taking so long😄
Maybe you have to work on your communication, too. If it’s late, than only because we need to meet our company’s quality goals. 😉
This week I was given the task of solving a bug on the application front-end. It looked simple enough so I said when I asked that you should be solving by tomorrow (Monday). Well, I still have no idea how I'm going to solve it. It is basically some bug around Samsung smartphones' keyboard predictive text that makes the user input act like crazy. I tried a lot of things already, but it seems Samsung was very crafty as to how to turn developer's life like hell. u.u
Absolutely right, Im still struggling with that problem. If I plan to complete a task in one day, it takes 3 days. Even I try my best to follow the plan
Biggest problem is usually changing goal posts.
I think I estimate pretty well, but the stuff we agree on at the start is never 100% of what I'm actually end up doing.
But I could imagine, if you're a dev for a corp das does everything waterfall style, and not for a startup, you could get the impression that estimation isn't that of a problem.
3pts ... Oh
I rather overestimate than underestimate. We use points to estimate in the team. If the estimates are far apart then the lowest and the highest explain their position, after which we estimate again. Of course some stories can take longer based on uncertainty but I don't feel I have to estimate low in order to impress my team.
You're an exception William, maybe you're one of those 10x's 😄
When it comes to frontend nowadays I feel like I am really good at estimate tasks. We estimate a task and it's risk separately. For example this might be a half a day task but it has a big risk (two days). So it's fine if that task spans for 2.5 days. Also modern frameworks like angular made predictions even easier due to their structured nature
Yeah, I agree with this, to be honest, a lot of my dodgy estimations are because of the unknown of the backend, but sometimes the frontend does catch me out!
Are you trying to describe me??
I need to improve on this as well. I once estimated a 5 month project could be completed in 1, maybe 2 months tops. Yeah, that didn't work out very well.
Since then I have tried to be more pessimistic when estimating.
I have not got much better at it, but I haven't got worse as least 😊😊
😅 that's brilliant, I've never had to estimate an entire project but I can only imagine that's 10x worse, so, so many unknowns!
Back when I was a wee CS student a professor I respect a great deal told us to estimate the time and then just double it. At the time I think a lot of us only half-listened to all these "old guys". Now that I'm approaching old guy status I accept most of what they said. 🤣
That said, there's a reason why many companies/projects don't have precise, external roadmaps as to what's coming when. It's easier for things to slip than predict a hard date. Better to delay than "ship" something not ready.
I'm convinced it's more witchcraft than science, really.
Haha the older you get the more you realise that these old buggers actually made some sense 😄
I honestly don't feel too much like what you described - I know that I have the tendency to underestimate how long something might take me, so I just always go wa, way higher than that, so that I can be sure that I'll be done in the time I promised. Now, that might sound great, but I honestly believe that that's what cost me my last web development job. They went with someone else, and even though it took them just as long as I estimated it would take me, me saying it would actually take me that long tipped them off.
Haha love that