(This post was originally published in full on hackernoon)
Picture this, you were asked to write a program, and during the discovery phase of the discussions, you were asked how long it was going to take. The spotlight was on you and everyone turned to face you. On their faces you could see the real question they were asking… How long are you going to set us behind our actual target? Cause let’s face it, that is what they really want to know. How long do they have to wait before they can use and advertise that new feature to the market.
You start to feel the pressure that everyone is suddenly counting on you. Maybe you are the new developer on the team, the last thing you want to do is to let everyone down. Without any real research or details, you make a quick mental calculation and ballpark a time frame, based on what you know so far.
“It could take me about 6 weeks, give or take”, you say, all the while hoping they note you said “could” to imply speculation and not a fixed possibility.
“Okay! If you could bring that down to 4 weeks that would be fantastic yeah?” is what you hear.
Everyone is excited. Your manager is brimming as they note the time frame down and base plans around that schedule. They are expecting a working program in 4 weeks. You look around at everyone making plans around that time estimate, and that’s when it sets in, a nagging uneasiness at the back of your mind; you didn’t factor all the things that could go wrong and will go wrong. A nagging thought starts to settle in, there is something you definitely forgot to account for. Anyway, what’s done is done, you say to yourself. You decide you will do the best you can with the time you have and hope everything goes as close to the plan as possible. Let the journey begin.
During week 1, you finally receive the design documentation and program specifications. As you read the specifications, you notice some additional bullet points that were not mentioned in the initial discussion. You confirm with your manager if this is real or enhancement requests after the initial release. To your worst expectation, it is real and part of the initial requirements. You should have known not everything was mentioned in the discovery phase. You compare what you thought you were building with what you shall be building with the new design specifications. Sometime by the end of the week 2, you have managed to jot down a few options on what possible approaches you could take to tackle the problem. You have mentally weighed their observable pros and cons and are close to selecting a single approach. You scribble a quick flow chart and theorize a couple of tests that the program must pass and those it must fail, basically you define the boundaries of your testing conditions.
At the beginning of week 3, you have a clear direction to follow, you are aware you have only 2 weeks left but you feel confident enough since your action plan is already set, all you have to do is build the parts - and so you begin. Everything is going well and by mid week, you begin testing a few of the components you have built as you integrate them into the main program. In the middle of the third week, a critical bug gets reported on a different project and it requires your immediate action. You question whether it really is critical or just a slight exaggeration. Your manager promptly confirms it is critical, if you could get right on it. You really don’t have time for this but oh well you must take a look at it. What’s the worst that could happen you wonder. Naturally, you take on the task and sideline your current project. Suddenly, your co-workers are signing off and to your shock, it's already the end of the day. You spent the entire day working on the bug, and to your dismay it's the end of the day, you haven’t fixed the bug nor made any progress on the project you side-lined. You start to feel just a little nervous. The following day, you find yourself still working on fixing the bug, this time more voraciously; you have to get this done because all this time is costing your current project. Luckily by the end of the day, you have a working bug fix. You aren’t too happy with it because you haven’t had time to thoroughly test it, but then again you are way off your schedule.
By the fourth week, you can finally get back to your project. A feeling of urgency begins to creep up on you. This is the deadline week. You psych yourself up, if you focus on this and only this, you could pull it off by a hair. Just as you start working on the project, you get called into a sync meeting, everyone is giving updates and all other parties want updates so they can revise the time frame. You are shocked; you completely forgot about this meeting. That takes off another 40 minutes at least from your time. You can feel the need for an extension, however, you haven’t figured out how to ask for one. You quickly put together a few slides with your flow chart showing what you have done so far and what you need to do. If you are going to get an extension, you will need everyone invested in understanding why it is important you get that extension.
During the meeting you discuss what you managed to get done, the problems you encountered and how you intend to fix them, for those you still haven’t worked on, you discuss the strategies you intend to take when implementing them. Finally, with all the cards on the table, you make a request for an additional couple of days to complete your part of the project. Your manager eyes you curiously, then says okay, you get your extra week. You remain level headed, but inside you jump in relief. You didn’t need a whole week, but with a whole extra week, you could actually conduct additional testing. As you work to complete the project, you make a mental note to next time, not give time estimates, or better yet, ask for time to think about how long you actually think it will take. However, deep down, you know you will be doing this fantasy time estimate all over again on the next project, because for some reason, that is just how it goes.
So why is this all just fantasy? Giving time estimates is something we have to do all the time during software development. Whether we estimate correctly or not, it is something we rely on and base decisions around.
In a follow up post, "Why your time estimations don't work and how to get better at estimation", I will highlight why time estimates mostly don't work and how to get better at giving near-accurate estimates.
Hope you enjoyed reading thus far! Let me know in the comment section.
Top comments (0)