One of the things that I particularly care about is proper task estimation. I genuinely believe that this is one of the essential traits of a successful programmer.
Why estimation matters at every level?
Let’s start from discussing the importance of estimation from the business perspective. The Product Owner or any other business handling person cares about the schedule and may change or adjust future task priorities based on the evaluation. Having reliable due dates is crucial in preparing a solid overall plan for the IT department and the whole company.
On the lower level — the team level, the importance of accurate estimation only increases, because your responsibility affects your teammates relatively more than it affects the whole business. People within a team are usually treated as a single body, and failing to provide correct work predictions impedes the work of others in this closely related group. The truth is that if you want to be perceived as a reliable teammate and build trust toward you in the closest group, you need to fulfill your promises regarding your work.
On a personal level, truthful estimation is at the core of being professional. Knowing what you are capable of, also in terms of time, presents the full value of your technical knowledge. That’s what you should aim for, because being professional is a core factor in driving motivation and inducing progress in your career. Being a better programmer is knowing more and knowing how well you can use the knowledge.
Why do you do it badly?
There are a couple of things that usually happen when we delve in to learn the reasons for a miscalculated judgment.
The most common one is guessing, and you may encounter it on various levels. You may guess the whole estimation at once, or you may guess specific elements and sum them up. Either way, you put yourself in trouble when your assumption is not correct. However, the problem is not the guessing itself, because let’s face it, when we predict the future, we always guess a little bit. The problem is that you may make presumptions without having considered reliable predicaments or any insights at all.
The second thing that is quite common is that you may not estimate the whole development process. There is more than the code you need to modify and the scripts to adjust. There are things like code review, testing, integration, preparing deployment, and probably more duties besides coding the solution. In the end, a higher but more accurate estimation works better than later explaining why you need to attend to one last additional thing before you can check off the task.
The last problem I see quite often is the decline in the code quality when the time left happens to be not enough. For the sake of the argument, let’s state that the code quality is essential. Maybe we will come back to this in the future to understand why that is so. As a professional, you should care about the quality because you are responsible for the company, your team, and your future self. That should be your goal. Understandably, sometimes the code quality is not the number one priority, but that cannot be accepted lightly and should always be a concern worth addressing. In situations like this, you should instead consult others and try to save the quality instead of unilaterally decide to give up on it.
What can you improve?
You should consider a couple of things when you have a problem with the proper estimation of your tasks.
You should spend more time on estimating the tasks. It should be crystal clear to everyone around that understanding the goal, clearing things up, and briefly acknowledging possible obstacles takes time, so that your estimations can become reliable. There is nothing wrong with analyzing your job step by step, focusing extra on details that may change the concept, and noting critical decisions behind the reckoning. This process usually speeds up with experience, but it always takes some time.
I need to mention that on different occasions, you may consider spending less time on the estimation. You see, the pragmatic approach tells us that we should spend the proper amount of time on the evaluation to make it the most beneficial. Spend less and you end up making a gamble; spending more, on the other hand, is a waste of time. You should be the judge, but remember that you can always ask for help from a more experienced teammate. Then, you should quickly see which aspects are vital for a good estimation.
When you find yourself in a situation where you know for sure that the time you anticipated won’t be enough, you should report that right away. There is no time to waste, and the key ingredient in managing such situations is fluent truth-based communication. It is useful to know how important your part is and who awaits its completion.
Probably the most valuable takeaway from the whole topic of estimation is to do it with care and retrospect when you have the results. The entire approach where you spend enough time to make an informed judgment brings the best results when you take your time after your task completion and look at the outcome. Consider what went different from your estimated baseline. Where have you spent more, where less time? Could you have foreseen that? Would you predict that in the future? When you make the educated decisions and learn from the outcome, you will make a significant progress very quickly.
Be professional, estimate reasonably, and good luck!