Chapter 1: The Myth of Accurate Estimates

When developers consistently provide precise and dependable estimates, it can often be mistaken for a sign of maturity and expertise. However, this expectation conflicts with the inherent nature of software development.

How Trustworthy Are Estimates?

The most challenging aspect of software development lies in accurately understanding the requirements. As I often mention, once we have a clear grasp of what needs to be done, the work is essentially complete. The real challenge for developers is translating customer needs into code, with the bulk of the effort focused on defining all potential scenarios. Since computers do not tolerate ambiguity, developers must invest significant effort into uncovering and resolving any missing requirements.

The level of detail in these requirements directly impacts the reliability of estimates. The more comprehensive the details, the more accurate the estimates will be. Any overlooked detail can lead to unforeseen consequences, affecting other requirements and extending the overall timeline. Consequently, developers frequently break down stories into smaller tasks to enhance their estimates, but this additional effort may not always yield worthwhile results.

There’s also a crucial principle to consider: the more specific an estimate, the less reliable it tends to be. For instance, when estimating a small task, we might suggest either one hour or less than one year. While the one-hour estimate appears more precise, it could easily be off if the task takes longer—say, two hours or even a day. On the other hand, estimating "less than one year" is far more likely to be accurate.

Possible Outcomes of Estimates

Upon completing a task, three outcomes can manifest:

1. The functionality is delivered right on schedule.
2. The functionality is delivered ahead of schedule.
3. The functionality takes longer than anticipated to complete.

While all three scenarios are valid, the second outcome often seems unrealistic. It is common for developers to be overly optimistic, frequently requiring more time than initially estimated. Thus, the most prevalent outcome tends to be the third: developers typically need more time than they anticipated, and it is rare for them to finish tasks quicker than expected.

The Unlikely Scenario of Early Completion

It’s easy to assume that developers are inherently optimistic, leading to the rarity of early completion. However, the reality is more complex. Often, developers misjudge estimates due to a lack of comprehensive knowledge about the requirements upfront, resulting in a degree of improvisation that introduces uncertainty.

Another factor contributing to inaccurate estimates is that developers frequently focus solely on adding new code without considering the necessity to interact with or refactor existing code. Even when older code is taken into account, if the project isn’t recent or the developer isn’t working alone, the legacy code may be extensive and riddled with unknowns, further complicating the estimation process.

Experienced developers are generally more aware of these uncertainties and understand how they affect estimates. They strive to minimize unknowns before providing an estimate, which often leads to more reliable predictions. However, when estimates are expressed in story points that are then translated into days or hours, this specificity increases significantly. For instance, a one-week story with just a 10% deviation could result in a project finishing nearly a day earlier or later, making on-time completion almost improbable.

Can Developers Control Their Estimates?

Consider this analogy: if you have a limited lunch break, the type of meal you choose influences how you spend that time. If you have a simple sandwich, you might finish quickly and have time to chat. However, a more complicated meal will likely consume your entire break. Similarly, experienced developers can maneuver around estimates in their work.

If the implementation takes less time than anticipated, they might engage in maintenance and code cleanup, which, while necessary, wasn’t included in the original planning. Conversely, if the implementation exceeds the estimated time, they may reduce the project’s scope to deliver sooner. In some cases—often with less experienced developers—this leads to insufficient testing and an increase in bugs.

Neither scenario is ideal. The first may lead to overengineering issues, and neglecting necessary maintenance tasks hinders prioritization. The second scenario is equally concerning: developers should not independently make decisions to cut corners.

Expectations for Developers

We expect programmers to demonstrate a high level of responsibility and discernment, but certain decisions should be communicated. This does not imply that developers must notify others when they find spare time for maintenance; such technical decisions are best left to their judgment. However, they should consistently perform maintenance and design corrections as needed.

Developers should also inform stakeholders when tasks start taking longer than anticipated. Instead of rushing through to meet deadlines or skimping on testing, it’s crucial they communicate these challenges so that collective decisions can be made.

Even when it’s desirable for developers to meet deadlines, they must make the implications of enforcing estimates clear and not make significant business decisions unilaterally. It's important to note that these challenges often stem from tasks being too large; smaller tasks can facilitate greater transparency. For instance, using Behavior-Driven Development (BDD) can help teams focus on one scenario at a time.

The Core Role of Developers

Ultimately, developers are tasked with automating processes. This is the primary goal of any software product: to replace slow, costly, or even unfeasible manual processes with automated solutions. A proficient developer should aim to streamline their own development processes as well, which is often evident when they create new tools or propose new abstractions that enhance speed and efficiency.

When a task becomes predictable, it typically means there is a significant amount of automatable logic involved. Developers should be adept at identifying which elements can be automated, creating new artifacts, and, as a result, accelerating the coding process. This leads us back to the idea that reliable estimates may indicate that something is not functioning as it should.

Conclusion

Despite our instincts suggesting otherwise, consistent accuracy in a developer's estimates may not be a positive indicator. As we have explored, potential underlying issues include:

• The developer completed the task early but spent time on maintenance tasks that should have been part of the initial plan.
• The developer would have finished later than estimated but cut corners, leaving functionalities untested.
• The developer failed to recognize tasks that could be automated, incurring additional costs.

Thus, if a developer consistently nails their estimates, it may be wise to approach such accuracy with skepticism.