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

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

Gantt

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!