How to Estimate the Duration of a Task

Eight strategies you can use to give better estimations as a software engineer.

Hi Friends,

Welcome to the 147th issue of the Polymathic Engineer.

"How long will this take?" is a question that makes most software developers feel bad, especially if they are reading a bug report or a new feature request that is difficult to understand. Despite that, this question will be asked of you many times.

The reality is simple: businesses need to plan. Product managers need to know when features will be ready. Project managers need to plan releases. Engineering managers need to allocate resources. Estimating is a necessary part of the job, whether you like it or not. There is no way to dodge it.

Here is what separates reliable engineers from the rest: solid estimators give accurate estimates and are clear about what they don't know and which delays might happen. They don't just throw out numbers and hope for the best. They know what needs to be done, see the risks, and are honest about their doubts.

The good news is that you can learn how to estimate. It's not a magical skill that only top developers have, but everyone can get better at it with practice and the right way to do things. What’s important is to know that different types of work need different ways of estimating, and to know which method to use when.

---

Why 90% of AI Agents Never Reach Production

This issue is offered by OutSystems. Most AI projects stall before production, not because the models fail but because the systems around them do. OutSystems built their Agent Workbench to overcome those hurdles. Featuring clean data integration, real orchestration between agents, and built-in governance. It turns promising demos into production-grade systems that scale.

Learn how you can get your team closer to agent deployment.

---

1. Past Experience

If you have done something similar before, you already have the most valuable piece of information to give a good estimation: actual data from a comparable task.

Let's suppose you need to add a new API endpoint that follows the same pattern as the three others you made. You know exactly what needs to be done: changes to the database schema, approval of requests, implementation of business logic, handling of errors, and tests. Even better, you remember how long each part took the last time.

This approach works so well that experienced developers often break down unfamiliar work into smaller pieces that resemble more familiar tasks. They are not just making the job more manageable, but also creating opportunities to use their experience for more accurate estimates.

The trick is to keep a list of all the things you have done. Do not just finish a job and move on. Take a moment to record how long it took and what made it take that long. These details become invaluable for future estimates.

2. Similar Work Done by Colleagues

When you need to face something new, chances are that someone on your team has already solved a similar problem. Having a conversation with those people can save you hours of uncertainty and give you a solid foundation for your estimate.

However, there is an important caveat: don't simply take their time estimate and use it directly. Your colleague might tell you "Oh, that took me about a couple of days," but remember that they already knew the codebase, understood the requirements, and had context you don't have yet.

The best approach is to break down their work with them. What were the main steps? Where did they get stuck? What took more time? Once you have their breakdown, add buffer time for your learning curve.

A good rule of thumb is to add 50-100% more time when you're doing something for the first time. How much more time you need depends on how different it is from your normal work. This isn't pessimism, but a realistic plan that accounts for the learning process.

3. Refactoring Projects

It's tricky to guess how long refactoring will take because you're changing how code works but not what it does. Most of the time, the steps are the same: understand the code that's already there, write tests to make sure the behavior stays the same, make small changes, and make sure everything still works.

However, the scope can easily grow as you discover more issues. This is why the best strategy for refactoring estimates is timeboxing. Instead of trying to predict how long it will take, set a fixed amount of time you're willing to spend. "I'll spend three days refactoring this module, and whatever improvement I can make in that time is what we get."

Timeboxing works because refactoring has diminishing returns. Most of the time, you get 80% of the value of refactoring on the first day. You might get the last 20% in the next few days. By setting a clear limit, you avoid the trap of endless refactoring while still improving the code meaningfully.

4. Building from scratch using well-known technology

This situation is often easier than it seems. You're building something new, but you're using tools and frameworks you know well. The main risk is when you have unclear or changing requirements.

Spend time clarifying the requirements upfront. What exactly should this feature do? What are the edge cases? How should it behave when something goes wrong?

The biggest mistake developers make in this situation is rushing to estimate before they fully understand the scope. Break down the work into concrete steps. Since you know the technology well, you can estimate each piece with reasonable confidence.

Another thing to be aware of is that adding new features often means making more design choices than you think. Where should this logic live? How does it interact with existing systems? Should we build it as a separate service or add it to an existing one? It takes time to make these kinds of choices, even when they are easy to carry out.

5. Integration with Unfamiliar Systems

This is where things become complicated. You need to connect to or build on top of another system that you don't fully understand. It could be an API owned by another team, a service from a third party, or a legacy system with poor documentation.

The most significant risk is that the system might not work the way it was supposed to. There might be hidden rate limits, error conditions that aren't explained, or weird authentication rules. An integration that seems easy can take days of troubleshooting and workarounds.

The best strategy is to build a prototype. Take a day or two to make a simple proof-of-concept that actually talks to the other system. Try the happy path, but also test a few error paths. Does the API return the code described in the documentation? What if you send requests that aren't correct?

Prototyping helps for two reasons. First, it gives you confidence that the integration is possible. Second, it gives you real data to use for estimating instead of guesses based on documents that could be wrong.

If you can't do a prototype for some reason, try to give two estimates: one where you assume everything works as documented, and another that assumes you will hit some undocumented issues and need time for workarounds.

If you have to give an estimate quickly, always go with the second one. You'd rather have extra time than have to rush to explain why a "simple" connection is taking so long than planned.

6. Simple Task with an unfamiliar Mature Technology

In this scenario, the work itself isn't complex, but you need to learn a new language or framework to do it. The technology is stable and well-known, but you haven't used it before. The most time-consuming thing here is getting used to the new technology.

The best starting point is to find someone on your team who has used this technology before. They will help you figure out how long it takes to get things done. However, takes everything with a pinch of salt. It's easy to forget how long it took you to learn something. They might remember getting things done, but they might forget the first days when they had trouble understanding basic ideas or setting up their environment.

If you can, pair with someone who knows the technology well. This can save you a lot of learning time and help you avoid common beginner mistakes. When pairing isn't an option, consider timeboxing your learning phase. Give yourself a specific amount of time to work through tutorials, build small examples, and get comfortable with the basics.

Don't forget to add time for debugging. When you're new to a technology, even simple bugs can take much longer to solve because you don't know the common patterns or where to look for help.

7. Using cutting-edge or new technology

New frameworks or languages are riskier than older technologies. The documentation might be incomplete or wrong, and the community is smaller, so when you get stuck, it's harder to find help. Also, bugs are more likely to show up in new technology that you'll need to fix.

It's almost impossible to estimate accurately without trying the technology first. The only way to know if something will work is to actually build with it. Pick the riskiest part of your project and try to implement it with the new technology. Can you connect to the database? Does the authentication work? Can you deploy it? This isn't about building the full feature, but only proving that the technology can do what you need.

Once you've built your proof of concept, you will have a much better sense of how the technology works and where the pain points lie. Only then should you try to estimate the full project.

If there is pressure to give an estimate before you have had a chance to try things out, be honest about the risks. Explain to them that new technology introduces unknowns that make estimation unreliable. Push for time to build a prototype first, even if it is just a few days.

8. Complex work with a lot of unknowns

On some projects, you must deal with unfamiliar systems, unclear requirements, and new technology, all at the same time. In this situation, there are too many unknowns to make a sensible estimate. You don't know the system you are integrating with, you don't know the technology, and you are not even sure exactly what needs to be built.

When this happens, don't try to estimate the whole thing. Instead, break down the job into smaller pieces, where each piece has only one major unknown. For example, you might split it into a small task to learn the new technology and build something basic, a separate task to understand and integrate with the unfamiliar system, and another task to clarify the requirements and design the solution

Each smaller estimate will be more accurate because you're only dealing with one unknown at a time. You can also prototype your way through the unknowns. Each prototype reduces the unknowns and makes the remaining work easier to estimate.