When asked to describe the qualities that define a great software developer, traits like effective communication, curiosity, teamwork, a positive attitude, creative problem-solving, and quick learning often come to mind. However, one crucial yet frequently overlooked and undervalued skill is the ability to accurately estimate the effort and complexity of a specific task. This skill not only reflects a developer's deep understanding of their craft and environment, but also plays a pivotal role in the success of projects and teams. In this blog post, we will explore the importance of estimation and why precise estimation is often a signifier of more senior software developers.

The Importance of Accurate Estimations

As software developers, the estimates we provide carry significant weight and often have broader implications than we might anticipate. Although these estimates are not meant to be commitments or promises, they are frequently interpreted as such by our colleagues, both technical and non-technical. These estimates can influence project plans, roadmaps, budgets, and resource allocation. Consequently, an inaccurate estimate can reflect poorly not only on ourselves but also on our team, department, and even the entire organisation.

This significance is amplified when providing estimates to individuals outside our team and organisation. When dealing with vendors, industry partners, and clients, our estimates are even more likely to be interpreted as commitments. There is no faster way to disappoint a third party than by overpromising and underdelivering.

So why are our estimates often taken out of context and misconstrued as promises? The reason lies in the differing languages spoken by developers and everyone else. We understand that a task's complexity can vary and that our estimates are informed guesses - nothing more. However, others deal in absolutes. When they hear "probably tomorrow," they interpret it as "tomorrow." This misunderstanding can lead to miscommunication, such as a client expecting a quick resolution to a support case or the board anticipating forecasted revenue from a newly developed product or feature.

The Difference Between Junior and Senior Developers

It is clear then that accurate estimates are vital for any successful project. However, mastering this skill is a key factor that distinguishes junior developers from their more senior colleagues. In my opinion, it can also play an essential part in the success and rate of progress of a developer's career.

While you may think that being a good estimator comes down more to experience and expertise than to anything else, there are a lot more nuances involved in estimations. An estimate is a culmination of experience, ability, certainty, knowledge of the codebase, and an awareness of the wider environment.

Throughout my career, I have observed several common challenges that junior developers face with estimations:

Taking tasks at face value: Junior developers often estimate only what is explicitly mentioned in a ticket, overlooking hidden complexities or dependencies that may affect the overall effort required.
Limited knowledge of the codebase: New developers may struggle to foresee how changes in one part of the codebase can ripple through other components or external dependencies, impacting their estimation accuracy.
Overestimating their abilities: Early in their careers, developers may underestimate the time and effort needed to complete tasks, not yet fully aware of the intricacies involved or the potential for unforeseen obstacles.
Neglecting non-coding aspects: Estimation involves more than just writing code. Junior developers may overlook tasks such as writing tests, undergoing code reviews, or obtaining approvals from other teams, leading to underestimated completion times.
Difficulty in breaking tasks down: Junior developers may attempt to tackle large tasks as a whole rather than breaking them down into smaller, manageable sub-tasks. This can lead to confusion and inaccurate estimations as they wade through the complexity they have unknowingly ventured into.

Although juniors often struggle with estimating effort, it's important to note that senior developers are not infallible; they too face challenges. However, they are usually more adept at anticipating obstacles, breaking tasks into manageable chunks, and considering the broader implications of their work.

Good vs Bad Estimation

After discussing the importance of estimation and the common pitfalls, let's now explore some typical types of estimators - both good and bad.

The People Pleaser - Nobody wants to be the bearer of bad news, especially when it comes to important tasks and deadlines, but no one avoids bad news as much as the people pleaser. In an effort to stay in everyone's good books they provide estimates based on what they think people want to hear rather than the reality. You will often find people pleasers giving unrealistic estimates just to keep others happy. An example could be agreeing to a shorter turnaround and then working overtime to make it happen, often leading to burnout or setting unrealistic expectations for future projects.
The Overpromiser - A cousin to the people pleaser is the overpromiser. The overpromiser people pleases in a different way by providing estimates beyond expectation in order to appear more competent than perhaps they are. The overpromiser will often provide estimates without real investigation in order to seem in control and knowledgeable. However, often they underestimate the size of the task and are left looking incompetent, which can undermine trust and strain team collaboration. An example could be providing an estimate on a bug fix without investigating the issue first, stating something along the lines of "oh I know that what that is, it should be easy - 10 minutes tops". Low and behold 10 minutes go by and the issue is still nowhere near complete.
The Underpromiser - The opposite of the overpromiser is the underpromiser. The underpromiser purposefully exaggerates their estimates so that they can always better them, with the hope that this makes them seem like a better developer. In reality, however, their lack of accuracy makes them appear unreliable and can be just as damaging as overpromising, often leading to unnecessary delays and missed opportunities for optimisation.
The Evader - For fear of becoming a people pleaser or overpromiser, our next type of estimator refuses to estimate at all unless they are completely confident in their estimation. Choosing to evade the accountability of providing a bad estimate, the evader only acts in confidence. They hide behind terms such as "I don't know," "how long is a piece of string," and "I couldn't possibly say" in order to shirk responsibility. However, what they don’t realize is that providing no estimate at all can be more detrimental than offering a poor one, as it leaves teams and stakeholders without direction and unable to plan effectively.
The Adjuster - The adjuster understands that estimates aren't always accurate and can change as new information surfaces. By transparently adjusting their estimates, they help stakeholders prepare for potential changes and build trust through ongoing communication. This approach allows teams to stay agile and responsive to evolving project demands.
The Professional - The final type of estimator is the professional. Professionals understand that one estimate isn't accurate enough to depict the variability of software tasks. Instead, as described in Robert C. Martin's The Clean Coder, they provide three estimates; an optimistic estimate (perfect conditions), a nominal estimate (most likely conditions) and a pessimistic estimate (worse conditions). These estimates produce a distribution that highlights the possible timeframe for a task and allows project managers to better anticipate variance, leading to more realistic roadmaps and successful project outcomes.

While there are many types of estimators, few consistently hit the mark. It’s not about always providing three estimates but about understanding the nuances of estimation and striving for continuous improvement. If you can relate to any of the more negative types of estimator, ask yourself what actions you can take to improve your consistency and reliability.

What Your Estimates Say About You

By now, this should be clear: your estimates are more than just numbers - they are a reflection of your competency, consistency, and reliability. When you provide accurate and well-considered estimates, it demonstrates a deep understanding of your work and builds trust with your team and stakeholders. Consistency in your estimates signals that you can reliably gauge the scope of tasks, fostering confidence in your ability to deliver. On the other hand, frequent inaccuracies can lead others to question your expertise and dependability, potentially damaging your reputation. In essence, your estimates are a key factor in how others perceive your professional capabilities.

Improving Your Estimates

Having explored the variance, necessity, and importance of estimation, it's now time to focus on how to improve this critical skill. Estimation isn't just about guessing; it’s a craft that can be honed with the right techniques and mindset. Fortunately, there are many practical methods that aspiring developers can use to enhance their estimation accuracy. Let’s dive into some strategies to help you become a more reliable and confident estimator.

Knowing What You Know

Everyone loves a good four-box diagram, and one particularly relevant to estimation is the concept of unknown unknowns. By cultivating self-awareness and understanding the differences between what you know and what you don’t, you can factor in knowledge gaps and the potential for surprises in your nominal and pessimistic estimations. This approach helps you to be better prepared, justify your estimations, and support them with sound reasoning.

Known Knowns - These are things you know that you know.
Known Unknowns - These are things you know that you don’t know.
Unknown Knowns - These are things you don’t realize you know.
Unknown Unknowns - These are things you don’t know that you don’t know.

Let's look at this concept through the eyes of a worked example. Imagine you are tasked with improving the performance of a webpage by reducing the amount of upfront load and necessary database calls.

Known Knowns - You may already be aware of the tools and techniques available, such as lazy loading, caching strategies, and optimizing database queries and have experience of using them in other projects.
Known Unknowns - You might know that there could be performance bottlenecks within your current database structure, but at this stage you're not sure where they are or how significant they might be in regards to improving the performance.
Unknown Knowns - You might have access to team members or resources with relevant expertise that you haven’t fully explored.
Unknown Unknowns - While working through the problem you might discover unknown dependencies or interactions within the codebase that you weren’t aware of. It could be that code is more tightly coupled that you realised meaning that the change you were planning to make might have unintended knock-on effects throughout the wider system.

When you start to view problems through this lens it is easier to avoid overly optimistic estimations as you are bringing the possibility of unknown obstacles to your attention.

Get To Know The Codebase

Just as a surgeon wouldn't operate without a thorough understanding of human anatomy, software developers shouldn't work without a deep knowledge of the codebase they're working on. Fortunately, gaining deep knowledge of your codebase doesn’t come with a hefty price tag or years of training, but it can be just as rewarding for your professional career.

When you have a thorough understanding of the environment in which you're working, you minimise the risk of nasty surprises. This not only makes your estimates more accurate and reliable but also provides the satisfaction of becoming a true domain expert. Best of all, achieving this level of understanding is possible regardless of your experience.

For a deeper dive into practical methods for mastering your codebase, check out this detailed guide.

Provide a Range

We've already touched on this in Good vs Bad Estimation, but get used to providing a range of estimates instead of a single estimate. If your team only deals with one estimate currently, propose the idea of providing more than one. For example, workflow management tools like Jira often allow you to customise your tickets with as many pieces of information as you'd like, allowing you to represent all your estimates on the ticket. If the team shoots down your idea, then you can continue to implement the approach alone by communicating your optimistic, nominal and pessimistic estimates when you start a new piece of work.

Take Time to Reflect

While team retrospectives are a key part of agile software development, individual reflection on a task-by-task level is a technique that’s often overlooked. Yet, it’s something you can easily implement to consistently improve your estimation skills. By taking time to reflect at the end of each task, you can identify aspects you’re proud of and areas where you may have fallen short.

Consider a task you either grossly underestimated or overestimated. Reviewing why your estimate was off in hindsight allows you to apply that knowledge to future tasks. If you simply move on to the next task without reflection, you miss an opportunity to refine your ability to estimate accurately. Not only that, but reflection can also highlight areas for improvement in other aspects of your software development career, such as code quality, test coverage, and documentation.

Conclusion

Estimation is more than just a technical skill - it's a hallmark of experience and professionalism in software development. As we’ve explored, the ability to accurately estimate the effort and complexity of tasks is essential not only for the success of individual projects but also for the long-term trajectory of your career. Accurate estimations build trust, enhance collaboration, and drive better decision-making within your team and organisation.

Whether you’re just starting out or looking to refine your skills, remember that great estimators are made, not born. By understanding the common challenges, learning from your experiences, and continuously improving your knowledge of the codebase and your environment, you can become a more reliable and respected developer. Estimation is a craft that evolves with time, practice, and reflection. Embrace the journey, and you'll find that the rewards extend far beyond just hitting deadlines - they define your impact as a developer.

As you continue to hone this vital skill, keep in mind that your estimates are more than just numbers. They are a reflection of your competency, consistency, and reliability, influencing how others perceive your professional capabilities. So, invest the time to master the art of estimation, and watch it transform your work, your team’s success, and your career.

Estimating Effort: The Mark of an Experienced Developer