Whether you're a junior, senior, project manager, or top-level manager with 20 years of experience, evaluating the time of a software development project is never an easy task. No one, regardless of his experience and genius, can claim to know the exact time of completion of the program project.
This problem is particularly relevant in software design, but other engineering disciplines suffer from the same. Therefore, although this article refers to software design, it is to some extent related to other disciplines.
Let's first look at the problem, its consequences, and potential root causes from a bird's-eye perspective.
Problem
Program projects rarely fit into the deadline.
Impact
Wasting marketing costs, customer frustration, exhausted developers, eating low-quality code to meet deadlines at the cost of reducing product reliability, and ultimately - the likely termination of the project.
Known Reasons
- Incorrect time estimate (the main topic of this article).
- The requirements are unclear at the start of the project, with their subsequent modification.
- Decorations: too much attention is paid to details that are not relevant to the project's essence.
- There is not enough time devoted to the stage of research and design of architecture. Or vice versa, too much time is spent.
- Underestimate potential integration issues with third-party systems.
- The desire to "do everything right the first time"
- Parallel work on too many projects or distraction (too often thread interruption).
- Unbalanced quality/performance.
Excessive optimism is pure uncertainty or just mathematics?
You can immediately discard excessive optimism - it is logical that no developer who has ever experienced problems with deadlines will be optimistic when choosing them. If the project management does not have engineering experience and does not understand what it is doing, then this is a topic for a completely different article.
Some associate erroneous time estimates with the Dunning-Kruger effect, but if underestimating time is associated with a lack of experience or a reevaluation of abilities, then gaining experience should definitely solve the problem, right? However, even the largest companies with almost infinite resources still have surprisingly high rates of missed deadlines, so this hypothesis is refuted. Not to mention the fact that we all experienced it on ourselves. Having more experience almost does not help in estimating time.
Many developers, especially the most experienced of them, quickly come to the conclusion that it is exclusively about uncertainty. Therefore, time estimates will always be erroneous and this is just a life fact. The only thing we can do with this is try to satisfy the requirements of the client and ask the developers to "just tap" when everything goes awry. All of us are familiar with the stress, garbage code and perfect chaos created by such a philosophy.
Is there a technique in this madness? Is this really the best way to solve problems? I don't think it is, so I decided to go looking for a rational mathematical explanation of why all these smart people can't estimate the time it will take them to do the work.
It's just math!
Once I performed a task that was supposed to take 10 minutes, but ultimately required 2 hours. I began to reflect on why I decided that it should take 10 minutes, and how this number grew to 2 hours. My thought process was quite interesting:
I thought it would take 10 minutes, because in my head on the 100% I knew the code to write.
Writing the code actually took about 7-10 minutes. And then it took 2 hours because of a completely unknown bug in the framework.
In project management, they like to call this "force majeure" - external uncontrolled causes of delay.
Perhaps you now think that with this example I confirmed the argument about the uncertainty of planning. In fact, and yes, and no. Let's take a look from afar. Yes, indeed, uncertainty was the root cause of the delay in this particular task, because I would never have guessed that such a bug existed. But should she be responsible for delaying the entire project?
Here we need to draw a boundary between a single task that is not representative of the whole process, and vice versa.
How we estimate time under "normal" conditions
Normal distributions occur everywhere and the human brain has mastered them well. We are specialists in evaluating processes that are inherently following a normal distribution; this is the basis for learning from experience.
If this month you went to the nearest store almost 20 times and each time the journey took 5 minutes, except for the case when the elevator broke and you had to wait 10 minutes, and also the case when you decided to wait two minutes until the rain was over. How long do you estimate it will take to get to the store right now? Five minutes?
I mean, it makes no sense to say "15 minutes," because this is a rare case, or "7 minutes," unless there is rain on the street. And you're likely to be right. If in 18 of 20 cases the path took 5 minutes, then there is definitely a high probability that it will take 5 minutes (median) this time. The probability is about 90% (if, of course, not to go into more complex calculations).
But the schedule is distorted!
Even if you are good at evaluating the time to complete a task, this does not mean that you will appreciate the time to complete the project! It's counterintuitive, but you can make a big mistake.
Programming tasks in a project are usually quite similar to each other, or at least grouped into several similar clusters! It also follows from this equation that this problem is scalable! Although we want everything in software projects to be scalable, problems are clearly not welcome.
How can we benefit from this knowledge?
Honestly, in the process of writing the article, I did not plan to give "recommendations" based on this hypothesis. It was supposed to be just an explanatory analysis, ending with a hypothesis, which the reader should interpret of his own free will.
However, I understand that many will be disappointed with such incomplete, so I will tell you what I personally took from this.
- It is easier to say whether task X will take more/less/as much time compared to task Y than to determine exactly how much it will take to complete them. So it turns out, because if the bevel of the curves is approximately the same (which is true for similar problems), then comparing the medians gives about the same results as comparing the averages.
- I do not remember or write down each individual task to perform calculations and obtain an average (and I cannot find any data for such experiments). Therefore, I usually estimate the inevitable error (mean-median) as a percentage of the time per task, which increases/decreases depending on how much I have mastered with the development environment. (Do I like this language/framework (40%) Do I have good debugging tools? (30%) Is IDE support good? (25%) … and so on.
- I began to divide sprints into tasks of equal size to ensure some homogeneity in the time assessment process. This allows me to use paragraph 1. It can be easy to determine that two tasks are approximately equal in time. In addition, this makes the problems even more similar to what the hypothesis applies to, and everything becomes more predictable.
- Using these principles, you can organize a "test run" if you have resources. For example, if X1 developers completed Y1 homogeneous tasks in Z1 days, then we can calculate X2 (days), knowing Y2 (the number of available developers) and Z2 (the total number of remaining tasks).