Understanding software estimates: why "one day" isn't just one day

Ever wondered why software projects take longer than estimated? Join Sarah and Mike in their office as they unravel the mystery of software estimates, explained in a way that everyone can understand.
From requirements to release
Estimating a new feature...
"How long will it take to add this new feature?" asks Mike, the product owner.
"About a day", replies Sarah, the developer, after quickly reviewing the requirements.

Three days later…
"Sarah, I thought you said this would take one day, but we've spent three days on it. What happened?"
Mike is confused and slightly frustrated.

This scenario probably sounds familiar to anyone who's been involved in software development. Let's explore why these misunderstandings happen and how we can better understand software estimates.
The hidden layers of feature development
When we talk about building a new feature, it's easy to think of it as simply writing code. However, the reality is far more complex. Imagine building a house - you don't just start putting up walls. You need to have meetings with the architects and the builder first. You also need blueprints, permits, foundation work, inspections, and much more.
Developing software features is similar. Here's what actually goes into building a feature:

1. Understanding what we're building
Before any coding begins, the team must fully understand what they're building. This involves meetings with experts, creating documentation, and sometimes designing mockups. Both the development team and business stakeholders need to be on the same page about what the feature should (and shouldn't) do.
2. Planning the solution
Once everyone understands what needs to be built, developers explore different ways to build it. Sometimes there's a quick solution that meets immediate needs, and sometimes there's a more comprehensive approach that might benefit future developments. The team presents these options, and stakeholders choose the best approach based on requirements and budget.
3. The actual development
This is what most people think of when they hear "building a feature." It's where developers write the code, but it's only part of the story. The development phase itself includes writing the actual code, followed by other developers reviewing it for quality and making necessary changes based on their feedback. This collaborative process ensures the code meets quality standards and follows best practices.
4. Quality assurance
After the code is written, it needs to be thoroughly tested. This often includes testing against the original requirements, creating automated tests to prevent future issues, and having different team members test the feature.
5. Final review and deployment
Finally, the feature needs to be reviewed by stakeholders, modified if any new requirements are discovered, and carefully deployed to production.

The 40-40-20 rule
In the software industry, there's a common rule of thumb called the "40-40-20 rule":
- 40% of time goes to actual development and code review
- 40% goes to non-development activities (meetings, planning, testing)
- 20% is a buffer for unexpected issues and general management
This means when a developer says "one day," they're often thinking about their part - the actual coding. But the total time needed is typically 3 times longer.
A better conversation
Let's revisit our earlier scenario, but with better communication.
Estimating a new feature...
"How long will it take to add this new feature?" asks Mike.
"The actual coding will take about a day", replies Sarah. "With code review and testing, we're looking at about 1.5 days. Then we'll need time for requirements meetings, final testing, and deployment preparation. All together, it should take about three days".

"That makes sense", Mike nods. "Thanks for breaking it down. I'll plan for three days in our timeline".
Three days later…
“Great work on delivering the feature on schedule, Sarah! Breaking down the estimate really helped me plan better".

The takeaway
Software estimates aren't just about coding time. They include all the necessary steps to deliver a quality feature that works as intended. Next time you hear a time estimate, remember to ask what it includes. Clear communication about these components helps everyone plan better and reduces misunderstandings.
Our experience at 1xINTERNET
With over a decade of experience in delivering complex software solutions and a growing team of more than 80 professionals, we've learned some valuable lessons about software estimation and delivery.
Our projects consistently show that actual coding time accounts for less than 50% of the total project duration in well-executed projects. Whenever we see coding time exceeding this ratio, it usually indicates gaps in planning or communication which leads to rework and delays.
We've found that the key to efficient delivery isn't in the coding itself, as we've already optimised our development practices. Instead, the greatest potential for improvement lies in better planning and closer collaboration with clients. While it might seem counterintuitive, spending more time in planning actually leads to faster overall delivery and more accurate estimates.
Other highlights
Why building on a preconfigured Drupal CMS is a wise investment

Drupal is a versatile CMS with extensive customization options. Configuring it correctly can be...
Using a MVP approach for web projects

At 1xINTERNET we use a MVP (Minimum Viable Product) approach for delivering successful web projects...