🧐 What Am I Thinking This Week

Have you ever crushed a task estimate, only to watch it spiral out of control?

Maybe you thought it would take a few days, but it stretched into weeks with endless testing and bug fixing. If so, you are not alone. In software engineering, task estimation is not about predicting the future. It is about communicating risk and reducing uncertainty.

Why Do We Estimate?

During project planning, estimating how long a task or feature might take helps the team understand the resources needed and the overall timeline. When multiple priorities compete for attention, estimation helps organize them and shift priorities as necessary.

Why Is Estimating Difficult?

Software development is not just about designing systems and writing code. It involves communication, reviews, and unexpected blockers along the way. When a project requires cross-team collaboration, you need to align on what you are trying to achieve, whether enough APIs are available, how to use them, and more. If a project involves a new system, you will also need time to read documentation and ramp up when estimating the effort.

Remember: we cannot possibly know everything.

What Can Blow Up Estimates?

Hidden complexity

You thought you could set up an interceptor or callback, but the documentation says it is not possible. Now you need to find another solution.

Changing requirements or scope creep

Requirements and priorities change all the time. Estimates will need to adjust when new features are added. Sometimes seemingly small feature requests are non-trivial from an engineering perspective. Ask clarifying questions and voice your concerns early.

Dependencies on other teams or systems

If other teams’ priorities do not align with yours and they delay deliverables, the overall timeline will shift. You will need to communicate this with stakeholders and propose alternative solutions if necessary.

Wrong assumptions

You assumed a system would behave one way, but the documentation or real-world behavior says otherwise. What seemed small might now become a major blocker or even an epic on its own.

Underestimating time for code reviews, testing, or QA

Always factor in time for proper testing, QA, bug fixing, and deployment. A project is not done until it is properly tested and delivered.

How You Can Estimate Better

Break down large tasks.

If a task seems too complex or large, break it into smaller, more manageable parts.

Call out risks and unknowns.

Highlight uncertainties when making estimates. Others may have insights that help refine the estimate or suggest creating a spike ticket.

Leave buffer for surprises.

Especially when uncertainty is high, build in a buffer to handle the unexpected.

Remember, you are estimating to help the team plan, not to be right.

Quick Mental Checklist Before Estimating

• Do I have all the requirements?

• Are there any third-party integrations?

• Is this truly a “known known,” or am I guessing?

• Has something similar been built before?

• What could go wrong?

• Should I prototype or spike first?

Closing Thoughts

Estimation is not about being right, it is about being real. The best engineers are not those who predict perfectly, but those who communicate uncertainty with clarity. Trust, not perfection, is what drives teams forward.

How do you approach estimates? I would love to hear your best or worst estimation and planning stories!

💡 The ONE Thing You Should Know

Interesting view about the future of web browsing. It reminds me of an anime called Mega Man Battle Network, where everyone has a digital agent that does work for them. We may no longer need browsers to navigate the web. Agents will find information, extract data, and act on our behalf. I wonder what the future of the advertising business will look like if no one actually browses the web anymore.