Ask the Expert: “How Long Will It Take?” The Question That Throws Every Developer

“How long do you need to finish this task?”

A question that sounds simple, yet it puts a developer in a real dilemma:

• Answer fast, and you commit to a date you may not be able to meet.
• Take your time answering, and you look unprepared, or as if you don’t understand the task.

Caught between rushing and hesitating, many developers fall into the trap of hasty estimates that later turn into pressure, delays and lost trust. So how do you estimate time accurately when you don’t have all the details yet?

Don’t estimate “the task”, estimate its parts

A phrase like “connect the interface to the system” looks like a single task, but it hides dozens of details underneath:

1. 1Analysing the requirements.
2. 2Designing the solution.
3. 3Building the interface.
4. 4Connecting it to the API.
5. 5Testing and review.

When you estimate the whole task in one go, you are guessing. When you split it into small steps, each step becomes reasonably estimable.

Rule of thumb: the smaller the step, the less likely it is to surprise you.

Know what you don’t know before you write the number

Before you answer, pause and ask yourself what information you’re missing:

• Is the API actually ready, or still under development?
• Is the design final, or could it still change?
• Are there permissions or edge cases that haven’t been mentioned yet?

Every unanswered question is a potential source of delay, and ignoring it doesn’t remove it; it only postpones it to a worse moment. So treat your estimate at this stage as an initial forecast based on what’s available, not a confirmed deadline, and be open about that with the people around you.

Code isn’t the whole story

A common mistake is counting only the time you’ll spend writing code. But writing is often the shortest part of the journey. There is also:

• Fixing bugs.
• Requirements changing halfway through.
• Integration problems with other systems.
• Review feedback.
• Sometimes, waiting for a reply from another team.

So include these risks in your estimate, and make the extra margin proportional to the real level of uncertainty:

• A clear task: a small margin.
• A fuzzy task: a larger one.

Adding a fixed percentage to every task without thinking is just guessing dressed up as maths.

Give a range instead of a single number

A single number quickly turns into a promise in other people’s minds, and going past it is seen as breaking a commitment. A time range expresses reality honestly.

Instead of “I’ll finish in two days”, try saying:

“I expect the task to take two to four days based on the information available, and I’ll give you a more precise estimate after reviewing the integration details.”

With that one sentence you have:

1. 1Given a realistic forecast.
2. 2Explained the reason for the uncertainty.
3. 3Said when the estimate will become more precise.

And that is exactly what the team needs to plan with confidence.

Your estimate evolves with your understanding

A good estimate isn’t a number written once and then defended whatever happens. It changes as you understand the task better. If you discover new complexity or information that changes the size of the work, tell the team early and explain how it affects the expected date.

A delay announced early can be managed and planned around. One discovered on delivery day costs you more than time: it costs you trust.

Before you answer: a quick checklist

• Have I split the task into small, estimable steps?
• Have I named what I don’t know yet?
• Have I counted the work beyond writing code?
• Is my margin proportional to how unclear the task is?
• Am I giving a range, and saying when it will become more precise?

The takeaway

A professional developer isn’t measured by the ability to predict everything that will happen; that’s impossible. They are measured by their ability to:

1. 1Understand the scope of the work.
2. 2Name the unknowns.
3. 3Account for the risks.
4. 4Communicate honestly whenever the picture changes.

In the end, a team isn’t looking for the developer who promises the shortest time, but for the developer who, when they name a date, everyone trusts it.