Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Why it’s challenging to make estimations about code (plus a developer puzzle)


Um, could you move that pink part over a little?

In our everyday lives, we constantly try to estimate things: How long do will it take me to get to work today? How much money do I need for my monthly expenses? Do I have enough food for this big party I’m throwing? How much salt should I put into my wine? And so on… (kidding about the last one)

It would seem that making estimations is a natural part of our lives, so it’s no surprise to find it also in software development.

We all heard the stories of all these projects that got delayed over and over again beyond the initial planned delivered date, right? Could it be that the team was not able to estimate what was needed and for how long?

Let me pose a question: How long does it take to go from Paris to London? (Your answer: “It depends!”)

Right. The options could range from 1 – 10 hours or even more, right? Note that I have only asked you how much time would you take to get there, but never told you how you should get there. This is a major detail since it opens up a lot of travel possibilities, and since we are guessing, everyone has their own way to guess things. A few will go by plane, others by train, maybe a small minority by car, and maybe a few adventurous who would chose to go by bike.

Anyway, after agreeing on a way to get there, we decide to go by plane and that it shouldn’t take longer than 2 hours. Guess what? Flights are delayed due to the bad weather. Do you realize where this is going?

Making estimations for software is even worse…

For software projects, making estimations accurately is exponentially more complex–there is even a term for it: “scope creep”, which RebelLabs asked developers about in the Developer Productivity Report 2013 (PDF), which, among other things, asked about how the predictability of software/project delivery is influenced by tools and methodologies. Interesting findings in there.

Don’t think this is only applicable to old, monolithic projects long past their prime. Even with modern apps, you still want to know how much time it will take to fix the latest issue in production that’s affecting your users’ ability to buy your newest product. Time is money, right?

How can we improve then? There are several techniques, which I’ll cover in upcoming posts hopefully. But let’s start now with a very simple example that is many times overlooked…

Estimation gets considerable easier if you have more information about the particular task that you are going to perform. This is the ideal in the perfect world, but as we know, this is not always the case. What do we do when we don’t have enough information? We need to make Assumptions! Is this going to improve your estimation, or get it right? Probably not, but at least it will give you a common ground until you can fill in the missing pieces.

Let’s see how this goes in reality with a puzzle…see below!

Care to try a puzzle?

Imagine a customers asks: How long would it take you to implement a new feature related to funds deposits?

Look at the following code:

interface Bank {
	boolean depositFunds(Funds funds);

All you need to do is implement that interface. How long would you take? Let me know in the comments or on Twitter at @radcortez and I’ll get back into this in the next blog post series. Hint: there is no right or wrong answer and you probably need to assume some things.

Remember to send me your comments!

Up next: Java Parallel Steams Are Bad For Your Health!

  • Cedric Chaveriat

    As it is a new feature let assume Funds already exists
    But as depositFunds is a very basic (fundamental) feature of a Bank let’s assume there is no existing object that could just implements Bank so we have to modelize a whole bank with probably lead to create an Account interface… at least!

    I think the first thing to do is specify the needs : functional (what does depositFunds in details? what are the possibles states of Fund, Bank and others entities that could appear in the spec? what if somthing wrong happen?…) and non functional needs (a lot of security I guess, speed, thread safe of course!…)
    After the spec there is all the steps of software development management

    personally I can’t give any estimations without good specifications

    Specify mean several meetings, interviews, writing spec, validation… : probably several months just for the spec

    otherwise that :

    import java.util.Random;

    public class BankImpl implements Bank {
    public boolean depositFunds(Funds funds) {
    return new Random().nextBoolean() ;

    take me 2 minutes and I succeed to implements the interface, according to the JVM, but according to the client… I don’t think so
    In a TDD approach I could succeed according the tests, that’s much better, but I think it is still not enough

  • Roberto Cortez

    Hi Cedric, thank you for your response.

    Unfortunately, as you probably know, most of the times you are not able to build such a detailed specification, but you already did a good job there by enumerating the needs.

    Aren’t we able to provide a rough estimation knowing that we need to add security, thread safety? We can also assume that Funds object already has all the information we need to implement the method.

    Your implementation is great ;)

  • Eric Hill

    boolean depositFunds(Funds funds) {
    String developersAccountId = “0123456789”;
    Account bankAccount = ChartOfAccounts.lookup(developersAccountId);
    Account cashAccount = ChartOfAccounts.lookup(“CASH”);

  • nickread

    public boolean depositFunds(Funds funds) {
    throw new UnsupportedOperationException();