The Pragmatic Programmer: Notes on Estimations

Let me start by answering the most frequently asked question in a Software Engineer's career!

How long will it take to finish this?

The answer you should give at the beginning is

I'll take that to the team and get back to you.

OR

I will get back to you.

Let me elaborate!

Where Do Estimates come from?

The process of estimating the time required for a specific task is data-driven. The accuracy of these estimates depends mainly on the data's quality and the task's understanding.

• The nature of the problem

• The nature of the available resources

  • Experiences and Team Capacity

  • infrastructure

  • Time

  • Money/Budget

• The outside factors (unplanned, uncontrolled surprises)

To create an accurate enough model, you need to consider these factors. Let's break down each one of them

First, Understand the problem better than your customer

The customer here is not just someone from outside. The customer can be a CEO, a manager, or anyone requesting the task. Often, people don't fully understand what they are asking for. But you need to know and understand it well!

Start by asking questions about the requirements and scope of this task. What are the expected outcomes and what use cases need to be covered?

Asking these questions and gathering information about the problem should help you start working on a mental model of it.

Sometimes, people ask for X, but after they explain what they want, you find out they only need Y. Figuring this out early is crucial for making accurate estimates and avoiding wasted time and resources on the wrong thing!

Understanding the nature of the available resources

Any task requires some sort of resources, for example

• Human resources: people working on it

• Architectural resources: Servers, Databases, ..etc

• Time: The time that will be dedicated to researching, developing, and maintaining this problem instead of another one

• Money: the cost of all of that to get this done and how does that align with the budget

In a perfect world, we would have an infinite supply of these resources. But as you already know, our world is far from perfect! After understanding the problem, you can start assessing how many of these resources you need and how many you have. It's also important to consider the big picture—how will this affect your other projects and commitments? Make sure to communicate this to the project manager and the team or department manager.

Taking the bad day into consideration!

After you assign a reasonable value for each parameter and feel confident in your initial estimate, you need to consider a buffer for unexpected events. I know it's hard to plan for these, but they happen often.

Always add an extra buffer; you will need it. The only way to get better at estimating this buffer is through experience. At least, this is the only way I know! If you know a better way, I would love to hear about it! Please!

Adding all of this together

After you go through these three steps, gather the information from each and use it to make an estimate.

One method we can use is called the "Program Evaluation Review Technique" or "PERT." It works like this:

"So now, How long will it take to finish this?"

"Well. If everything goes right, and we are sure that we covered all the requirements and usecases, this should take from the team having Member1 and Member2 focusing on it about 1 sprint (2 weeks). But that's unlikely the case, So I would guess a more realistic figure is close to 2 sprints (4 weeks). And of course, if we happen to have a huge blocker or urgent critical issues regarding the other operational systems that we currently have and needs the efforts of these members, we would need an extra sprint or a bit more"

As you can see, this method expresses 3 main scenarios

• Optimistic

• Most likely

• Pessimistic

With this approach, you spread the range of the uncertainty to levels, which helps to get a better estimation of the project as a whole

I know, people usually don't like this answer because it doesn't match the wall-sized charts they expect. Some think they have a formula for an accurate estimate. In my experience, the likelihood that they don't is high, and the chances that they've never done this before are even higher!

Track, Improve, Repeat

You probably went through this process, got an estimate, and found it wasn't accurate. Now what?

This process is ineffective if you don't track your estimates, learn from what went wrong, and apply those lessons next time. It's a feedback loop, an iterative cycle of improvement. Start somewhere and aim to get better each time!

Remember, it all starts with not rushing to give estimates the first time you're asked. Take the time to think it through. Don't forget the magic words.

I will get back to you.