1. Issues that you have encountered in the past (directly or indirectly) and you have a pretty good idea about the time needed to resolve it, even if there are some minor variations from your past experience
2. Issues that you have never come across before; in this case, estimating the time needed would prove to be more difficult
However, the first category of issues, contains a small subcategory of issues that rarely surface, but when they do, they can be quite a pain to deal with. I'm talking about issues that not only have small variations from your past experience, but on top of that, the context differs in which the issue appears differs also. Why is this a problem ?
Let's consider the first category of issues. Dealing with an issue that you have approached in the past is usually an easy task, regardless of the time needed, because once you have the necessary experience, you know which way to go. When approaching issues from the second category, if you're lucky enough to not have to specify a time frame, you can go at it at your own pace.
Now consider having to deal with an issue which you have solved in the past, but with a few variations and in a different context. Since you already have experience with it, you might be tempted to give a very optimistic time schedule because you disregard the individual details of issue. So instead of resolving the issue in, let's say, two hours, you end up doing it in two days. Not only does this screw up your schedule, but it can also be very frustrating to spend two days on a feature you initially planned to solve in two hours.
How can we overcome this kind of issues? Well sadly, there is no way to actually recognize one, until you have already missed the deadline. Then, you find yourself in the situation when someone comes you and asks to see your work and you have done only about 20%. I'm sure no one would like to be in that situation. But if you do find yourself in such a "mess", the best idea would be to split the issue in smaller steps.
What I mean specifically, is that the first thing to do is to break it up in the things that you have already resolved in the past and you can use that experience, and the ones that relate to this specific context. Next, make sure that you fully understood the issue. Nothing beats the frustration of finishing a task, and then having to make changes because you didn't understand the requirement all the way and you assumed some things that turned out to be wrong. Having this separation will help you in deciding what to focus on at any given moment, because clever as developers may be, they can only focus on one thing at a time :)
And one more thing that can really help overcome the issue is not being afraid to interact with your colleagues. I'm sure the at times, we find it hard to ask other people regarding how to solve an issue, because we assume that we'll appear unable to resolve it in the first place. That is a misconception. The experience you get by interacting with other people is much greater than the one you get by solving issues on your own. Even if you are absolutely sure you can solve an issue, if you (and they) have time to spare, present the issue and your method of resolving it. They could give you an alternative, which might actually work better (in this case don't be afraid of admitting it), or at least point out some details that haven't crossed your mind, which could help planning and save you a lot of time in the long run.
And if you have already been there, make sure you avoid the issue in the future by thoroughly examining each issue, regardless of its complexity, then making sure you have taken into account all the details that could screw up your initial estimate. This might sound like too much of an effort, but in time it will come natural to you, and hopefully you won't fall into the trap of underestimating the effort needed to resolve a seemingly simple issue.
Until next time, have a good one,
Romi
"Good decisions come from experience, and experience comes from bad decisions"
RăspundețiȘtergereHehe, we must get it wrong in order to get it right!
RăspundețiȘtergere