Why is it so difficult to evaluate development timelines (plus a task for developers)

    image
    Um, can you move the pink area a bit?

    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 assessment of everything around is a part of our life. So it’s not surprising to find the same thing in software development.

    We all heard about projects whose output was delayed again and again, right? Maybe this is due to the fact that the team could not correctly assess how much time they needed?

    Let me ask you a question: how long does it take to get from Paris to London? (The correct answer is “How will it turn out”).

    There may be options from 1 to 10 hours or more, right? Notice - I only asked how long it would take, but did not say how exactly this should be done. This is important because it leaves us with a choice of many ways to travel. And since nothing is explicitly indicated, everyone can choose their own method. Someone decides to travel by plane, some by train, some, perhaps by car or even by bicycle.

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

    Estimating development time is even worse ...


    For software projects, making an accurate assessment is much more difficult. To do this, there is even a special term " scope creep " - an 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 fix 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 upcoming posts. But let's start now with a small example.

    The easier it is to evaluate, the more information you have about the task you are about to complete. This is an 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 an assumption! Will this improve the score? It is unlikely, but it will at least give some ground until you find out the missing information.

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

    Task


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

    Take a look at the code:

    interface Bank {
    	boolean depositFunds(Funds funds);
    }
    

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


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

    Also popular now: