Asking for Estimates: The Telltale Sign of Ineffective Software Development Practices

When I think back to my early days of software development, one thing hits me hard: the obsession with estimates. 

I'm sure many of us have been in this situation. I’m seated in a conference room, sketching out the next big thing in  mobile app development for a retail project. My mind is spinning with technical challenges and roadblocks, but there’s always that one question hanging over me: “When will it be done?”

At first, it seems like a reasonable question. After all, clients and stakeholders need to know when they can expect to see results. 

However, as I’ve progressed through various retail and e-commerce projects, I’ve come to realize that relying on estimates can often be more of a hassle than a help.

Let me take you through this realization and how it reshaped my approach to software development.

The False Assurance of Estimates

Estimates are indispensable in software development. We use them to predict how long tasks will take, to plan sprints, and to manage client expectations. In my experience, estimates were often seen as a mark of professionalism. 

The more accurate your estimates, the more competent you seem.

However, I started noticing a pattern: 

No matter how precise our estimates were, they often proved to be unreliable. 

Deadlines would approach, and suddenly, we were trying to get everything done. It wasn’t just a matter of working faster; it was about compromising quality, rushing through testing, and cutting corners wherever possible. This wasn’t an isolated issue—it was a recurring problem.

I remember one particular e-commerce project where we were tasked with integrating a new payment gateway. The estimate for this feature was two weeks. As the deadline closed, it became clear that we were nowhere near ready. 

The team started making last-minute changes, sacrificing thorough testing to meet the deadline. 

The result? 

A problematic integration that caused issues for users and required immediate fixes post-launch.

The Wisdom of Robert C. Martin

In my search to understand why estimates fail so often, I came across the work of Robert C. Martin, a renowned figure in the Agile community. Martin is famous for his contributions to the principles of SOLID and TDD, and he also offered insights into the role of estimates in his book Clean Craftsmanship.

Martin’s perspective was transformative. He highlighted that while estimates are part of the development process, they should not dominate it. He introduced two essential “Bill of Rights”:

1. Customer Right: “You have the right to be informed of the schedule and estimate changes in time to choose how to reduce the scope to meet a required date. You can cancel at any time and be left with a useful working system reflecting investment to date.”
2. Developer Right: “You have the right to make and update your own estimates.”

These rights reflect a more balanced view. They acknowledge that while estimates are necessary, they should not dictate the pace or quality of the work. Instead, the focus should be on delivering value and maintaining a collaborative relationship between the business and development teams.

The Reality Check: Estimates Don’t Work as Expected

The more I thought about this, the more I realized that estimates often set us up for failure. They create a sense of urgency that leads to compromised quality. The classic scenario is the end of a sprint, where developers are pressured to complete tasks, often at the expense of best practices. This rush undermines the principles of Agile and Scrum, which emphasize sustainable development and quality.

In one of my retail app projects, we had a feature that needed to be developed by the end of the sprint. As the deadline approached, we found ourselves cutting corners—skipping some of the user experience tests and ignoring edge cases. While we met the deadline, the end product was far from perfect, leading to user complaints and additional work to fix the issues.

The Divide Between Product and Development

Another significant issue with estimates is that they create a divide between the product team and the development team. 

It often becomes a case of “us versus them.” 

The product team sets deadlines and estimates while developers are left to execute. This separation can lead to misunderstandings and conflicts, as each team may not fully grasp the other's challenges or needs.

I’ve seen this happen in projects where the product team demands quick delivery without understanding the technical complexities involved. This often leads to conflict and a lack of collaboration, which ultimately affects the project’s success.

Bridging the Gap: Collaboration Over Estimates

In my exploration, I discovered that the key to overcoming estimates' limitations is promoting collaboration. Instead of viewing the development process as a series of estimates and deadlines, we should focus on working together to achieve common goals. This shift in mindset has been transformative.

The Agile Manifesto emphasizes that 

“Business people and developers must work together daily throughout the project.” 

This principle has been crucial in my projects. By involving the product team closely with development, we can address challenges collaboratively and make informed decisions about priorities and scope.

In one e-commerce project, we decided to work closely with the product team from the start. Instead of providing estimates, we discussed the most valuable features and broke them into smaller, manageable tasks. This approach allowed us to deliver incremental value and receive feedback in real-time. It also meant that the product team was more aware of the development process and could make more informed decisions about feature prioritization and scope adjustments.

The Right Question: Moving Beyond Estimates

So, what’s the right question to ask? 

Instead of focusing on “When will it be done?” 

I’ve found it more effective to ask, 

“What is the next most important thing we can do?” 

or refined as, 

“What is the next smallest step we can take to validate and bring into motion the next most important thing that we can do?”

This question shifts the focus from deadlines and estimates to delivering value. It encourages teams to think about what can be achieved in small, incremental steps, which is more in line with Agile principles. By working in small increments, we can adapt quickly to changes, incorporate feedback, and continuously improve the product.

The Need for a New Approach

Adopting this approach requires a shift in mindset and practices. It means moving away from rigid estimates and deadlines and embracing a more dynamic and collaborative process. It’s about closing the loop between business and development, ensuring that both sides work together towards a common goal.

I’ve found that this approach improves the quality of the final product and enhances team cohesion and satisfaction. Developers and product teams become partners in the development process, working together to achieve the best outcomes.

Final Thoughts

It's challenging to break free from dependence on estimates and long-term planning, but it’s a necessary step towards a more effective and collaborative development process. By focusing on delivering value through small, incremental steps and fostering close collaboration between business and development teams, we can create better products and achieve greater success.

So, will you join me in challenging the status quo and exploring new ways of working? 

This is an invitation to rethink our assumptions and embrace a more dynamic and responsive approach to software development. The key is to change the question and focus on what truly matters: delivering value and achieving our goals together.