Why Software Developers Suck at Estimating Time (And How to Fix It)

You’ll probably recognize the typical software developer’s workflow:

Your boss approaches you with a new task. They ask you how long you expect it to take, so that they can plug it into their timeline for launching a new feature.

So you take your best guess to use as an upfront time estimate–perhaps it’s 10 hours.

But more often than not, this guess fails to account for all of the time that goes into developing a new feature, including related tasks like research, meetings with other team members (and check-ins with your boss), and inevitably debugging your code.

In this all-too-common situation for software developers, your 10-hour time estimate turns into 20 hours of time in actuality.

Does this sound familiar?

Aside from any personal anguish you may feel for being incorrect with estimating, you also have to deal with negative backlash from your boss. Part of your job involves making them look good, but if your imprecise estimates get in the way of on-budget, on-time delivery—they won’t soon forget that.

The solution? Improving time accuracy estimates with data.

But before we get to that, it may be helpful to discuss some of the most common reasons why software developers have issues with time estimate accuracy.

4 Things Software Developers Tend to Forget About When Calculating Time Estimates

Understanding the reasons why your time estimates are inaccurate is a key step in becoming a better predictor of time, and becoming a better software engineer in the end.

Most software developers are habitual underestimators for a few key reasons:

1. Parkinson’s Law

You’re likely familiar with the concept of Parkinson’s Law. If not, Parkinson’s Law refers to the idea that work expands to take up the entirety of the time you’ve set aside for it: regardless of how much time it would normally take.

To give an example, this means that if you’ve scheduled an hour time block for a task that would normally take 30 minutes, you’ll find a way to use up that entire hour. Of course, if you’re not sure how long a given task will take, this wasted productivity is to be expected.

2. Everyone is Different

Regardless of the fact that Bob has accurately predicted his ability to execute a given feature in a set amount of time has no bearing on you.

It’s important for both individuals and managers within a team to understand that time estimates are non-transferrable: everyone needs to do their own time estimating in order to be accurate.

3. Software Development is a Process

When you’re assigned a new task, it’s not just about writing code: oftentimes you’re also tasked with researching new concepts, collaborating with other software developers, and sitting in meetings related to the task at hand.

Most time estimates do not accurately account for all of the additional time that goes into a major task, which could be as much as twice your original estimate (or more!).

4. It Takes Time to Get “In the Zone” for Each Project You’re Working On

Did you know that it can take up to 25 minutes to get back on track after dealing with a distraction?

Oftentimes, software developers are working on multiple projects at the same time, waiting for input from other team members in order to move forward or finish a certain task. As a result, they’re constantly being pulled into and out of a given project. There’s a cognitive cost associated with constantly having to refocus on your current task, which can also impact your time estimate accuracy.

With all of these things in mind, you’re in the right mindset to improve your time estimate accuracy.

The Solution: Using Historic Data to Calculate Future Estimates

Why does all of this matter from a business standpoint? McKinsey found that 66% of enterprise software projects have cost (and effort) overruns.

With the way most projects are set up, an incorrect time estimate can have critical and exponential impacts on a business. Understanding how software developers normally estimate their role in a project timeline is the first step for increasing your team’s time estimate accuracy.

To try and rectify some of these measurement inaccuracies, many managers of software developers use time tracking as a strict mechanism in an attempt to keep projects on track. This approach can work—but only when applied as part of a more comprehensive planning process: involving input from your team.

The trick to making time tracking work for your team of software developers is to use historical data instead of raw estimates. You must coach each individual member of your team to improve their abilities to estimate and manage their own time.

Here’s how:

4 Steps to Effectively Tracking Accuracy over Time

Joel Spolsky, the Co-Founder of Stack Overflow, sets forth a simple process for tracking accuracy that any software developer can implement, regardless of the tools at their disposal.

Here’s how to track accuracy over time—a process also referred to as Evidence-based scheduling:

1. Use Available Data to Get Started

Have you used a software development time tracker before—whether on your bosses command or out of your own curiosity?

If so, take a cursory glance over the features you’ve tracked. This will provide a baseline of historic data to use. Did your time estimates match the reality as demonstrated by your recorded data? Does that data actually consider all relevant aspects of the project, including tasks like research, debugging, and meetings?

If not, you’ll want to get started now, if only for the purpose of improving your time estimate accuracy over time. If you don’t have a time tracking solution in place, you can download 7pace Timetracker free with a 28-day trial.

2. Calculate New Data Points for Every Feature You’re Responsible For

When calculating your accuracy with time estimating, there are no complex formulas required.

It’s simple. Take the time you originally estimated, then divide it by the actual amount of time it took you to build a feature.

3. Create a Plot of your Personal Time Estimating Accuracy Chart.

Here’s where things get interesting (and useful).

For each feature you’re tracking, perform the above calculation to get individual data points that represent your personal time estimating accuracy for each feature.

Once you have a few data points to work with, plot them on a graph to see your personal time estimate accuracy trend line, as such:

Source: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/

Depending on how many features you’re responsible for within your organization, you’ll start to see useful accuracy trends data in just a few week’s time.

4. Use Data to Predict Future Project Estimates

Now that you have more historic data to work with, it’s time to put it to use. Review your time estimate against the actual hours you spent on each task to uncover any discrepancies and to determine what went wrong.

Interestingly enough, Joel Spolsky states that it’s somewhat irrelevant as to whether or not your time estimating accuracy improves as the result of following this process. As long as you’re consistent with under- (or over-) estimating your time investment on various tasks, your boss will still be able to use this data to predict a project’s date of completion.

Source: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/

Spolsky’s process of evidence-based scheduling incorporates the Monte Cristo method, which suggests multiple possible dates of completion, as well as their resulting probability of likelihood.

Regardless of your improvements with accuracy, make sure to give your boss—perhaps even other team members with which you regularly collaborate—access to your personal data plot so that they feel empowered when putting together a complete project timeline.

The key to making this data useful over the long-term is consistency. It’s not worth starting if you can’t keep it updated over time—at least until your predictions start to match your actual time invested on features.

Final Thoughts: How to Reconcile When Time Estimates Don’t Match Reality

Being inaccurate with time estimates can result in negative outcomes for the organization you work for. For the sake of your company’s future, as well as your own, it pays off to become more accurate when forecasting the amount of time a given task will take you.

Develop this skill like you would any other in the workplace to become a better software developer.

After all, once you have committed to an estimate and have started a project/sprint/iteration, it’s too late to change things. The only way to get better at estimating is to use historic data to inform future predictions.

How do you effectively estimate time when it comes to software development projects and tasks? If you have a particularly effective method not covered here, tweet at @madeby7pace.