Why is it so difficult to estimate development time (plus a task for developers)

Um, can I move the pink area a little?

In everyday life, we are constantly trying to evaluate everything: how much time do I need to get to work? How much money do I spend per month? Do I have enough food for the upcoming big party? And so on…

It seems that the constant evaluation of everything around is a part of our life. So it is not surprising to find out the same thing in software development.
')
We all heard about projects that were delayed again and again, right? Maybe this is due to the fact that the team could not correctly assess how much time they need?

Let me ask you a question: how long does it take to get from Paris to London? (The correct answer is: "How come").

There may be options from 1 to 10 hours or even more, right? Notice - I just asked how long it would take, but didn’t say exactly how this should be done. This is important because it leaves us a choice of many ways to travel. And since nothing is explicitly stated, everyone can choose their own way. Someone decides to get on the plane, someone - by train, some, perhaps by car or even by bicycle.

After discussing all the ways, we decided that the fastest will be to fly on an airplane. And we should be in London no later than two hours, right? And now guess where flights were canceled due to bad weather. Do you understand what is going on?

Estimating development time is still worse ...

For software projects, making accurate estimates is much more difficult. For this there is even a special term " scope creep " - the uncontrolled growth of the scope of the project. Do not think that this applies only to old, monolithic projects that have long passed their peak. Even in modern applications, you need to know how long it takes to correct the latest errors, because of which the user does not want to buy the product. Time is money, isn't it?

How can we fix this? There are several techniques that I hope to talk about in the next posts. But let's start now with a small example.

It is easier to evaluate, the more information you have about the task you are going to perform. This is the ideal case, but, as we know, this is not always the case. What do we do if we don't have enough information? We must make a guess! Will this help improve the assessment? Hardly, but at least it will give some ground until you find out the missing information.

Let's see how this works on the example of the task ...

Task

Imagine a customer question: how long will it take to implement a new part related to deposits?

Look at the code:

interface Bank { boolean depositFunds(Funds funds); } 

All you have to do is implement the interface. How much time do you need? Hint: there is no right or wrong answer and you probably need to make some assumptions.

---

Translation of an article by Roberto Cortez , original by ZeroTurnAround .