Estimating the Effort of Development of a Django Application

This is a very common problem that every developer will eventually face at some point. Your boss or a client comes with a set of requirements and asks you to estimate how long it will take to implement them.

How to precisely (as possible) estimate the effort of development of a Web application? That’s a really tough question. People in the academia have being conducting research on that topic for at least the past 40 years, and yet we fail to get it right.

I wanted to write a little bit on that subject to try to highlight the challenges of making an accurate estimation and perhaps share some of my experience about it.

The Chaos Report 2015

Every year the Standish Group conducts a survey to investigate the cause of failure of software projects. In 2015, out of the 8,380 investigated projects, 16.2% (success) was delivered on-time and on-budget, 52.7% (challenged) faced challenges and was delivered over-budget and over the time estimate. The other 31.1% (impaired) was cancelled at some point during the development cycle.

Check this numbers in relation to the time overruns of the original estimates, from theChaos Report 2015:

Time Overruns

For the same combined challenged and impaired projects, over one-third also experienced time overruns of 200 to 300%. The average overrun is 222% of the original time estimate. For large companies, the average is 230%; for medium companies, the average is 202%; and for small companies, the average is 239%.

Time Overruns % of Responses Under 20% 13.9% 21 - 50% 18.3% 51 - 100% 20.0% 101 - 200% 35.5% 201 - 400% 11.2% Over 400% 1.1%

Scary, right?

Now, why does that happen? Mainly because every estimation involves uncertainty. An estimation is different from the reality because of the uncertainties . Make no mistake, every estimation will fail.

The software domain is plagued by uncertainties: incomplete requirements, volatile requirements, incomplete understanding of the scope, human aspects, external factors, etc.

We can’t help ourselves, we are not very good on forecasting things we don’t know.

How Uncertainty Behaves

There is an important aspect on how the uncertainty behaves. And this can help us a lot when estimating the effort. Let’s get back to the Chaos Report’s numbers. Out of the 8,380 applications analyzed by the Standish Group, 16.2% of them was delivered on time (possibly some of them took less effort than expected), while 83.8% required more effort than expected (when some of them wasn’t even concluded).

To illustrate that phenomena, I will quote the article How Uncertainty Works published by Kevin Thompson:

There is more room, in a mathematical sense, for work to grow beyond expectation than to shrink below expectation.

Mathematically speaking, the effort the accomplish one task can’t go below zero hours. But in the other hand, it can grow…

Sorry for the silly joke. Anyway, check the example Kevin Thompson gave in his article:

Assume we estimate this work at three days. The actual time may be more than three days over this estimate, but cannot be more than three days under the estimate!

In mathematical terms, we cannot estimate a task as requiring “X plus or minus Y days,” because the estimate becomes meaningless if Y is greater than X. What we can do is replace the concept of an increment of uncertainty with that of an uncertainty factor, F. This means that we think that X is the most likely duration, but the range of values is between X divided by F, and X times F. For example, suppose we estimate “Paint Bedroom” at 3 days, with an uncertainty factor of 2.

The most likely case is 3 days.

The best case is 1.5 days, which is 1.5 days under the estimate.

The worst case is 6 days, which is 3 days over the estimate.

I think this simple example illustrates well the concept.

Besides that, still, why are we so bad at making estimations? When it comes to estimating the effort of software development, we are over-optimistic. This is just one of the cognitive bias that affect our work.

The Cognitive Bias in Software Engineering

Actually, I know very little about that subject. But the little I read about it made lots of sense for me. Some of my collegues at the university study this subject in great detail, and listening to one of their presentations last year was the first time I came across that subject. And I thought it was fascinating.

I grabbed the information below from a great presentation by Julia Clavien on Cognitive Bias in Software Development .

So, what’s a Cognitive Bias?

Cognitive Bias

Systematic errors in judgment and decision making common to all human beings.

Daniel Kahneman

The Planning Fallacy

The tendency of individuals to display an optimism bias and underestimate the time and resource required to complete a project.

The Known Knowns, Known Unknowns and Unknown Unknowns

The plan is usually very different from the reality because of the difficulties to estimate what we don’t know, and even worse, to estimate things we don’t know we don’t know.

There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know.

Donald Rumsfeld

On the Wikipedia I found a very interesting citation of Jrgensen and Grimstad’s work, The Impact of Irrelevant and Misleading Information on Software Development Effort Estimates: A Randomized Controlled Field Experiment :

It’s easy to estimate what you know. It’s hard to estimate what you know you don’t know. (known unknowns) It’s very hard to estimate things that you don’t know you don’t know. (unknown unknowns) Minimizing the Problems

Let’s summarize what we have so far:

Estimation is different from reality because of uncertainty; There is more room for work to grow beyond expectation than to shrink below expectation; We have the tendency to be over-optimistic when it comes to estimate; It’s hard to estimate what we don’t know.

It is all about uncertainty. We certainly can’t eliminate it, but sure thing we can reduce it.

Decompose the Problem

Decompose the tasks into smaller ones. Try to look at them in great detail. Think about the underlying implications of the implementation of a given requirement.

Let’s say we have a task to implement a Password reset functionality .

We can decompose this task into several smaller tasks, and then estimate the effort of the small tasks. Naturally,