3 months vs 5 days

Whose Word Should We Trust?

This happened when I was working as a startup CTO.

After designing a feature, I called developer A, who had been with the company for a while, and asked for an estimated completion time.

The answer was "It will take about 3 months."

I was from a development background and had gone through similar projects many times.

Honestly, it didn't make sense.

So, I called a newly joined developer and asked the same question.

The answer was "It will take 5 days."

This moment is

a disaster for managers or executives without project experience.

3 months vs. 5 days.

The difference isn't just a matter of opinion;

it's a number that shakes up business schedules, resource allocation, costs, and investment timelines.

So, who should we trust?

Was Developer A Wrong?

Not necessarily.

Experienced developers often provide

1. Requirement changes
2. QA and communication costs
3. Technical debt
4. Post-deployment risks

as part of a "realistic timeframe."

The 3 months might not be "coding time" but rather

"time to take responsibility if something goes wrong."

Then, Was the Developer Who Said 5 Days Exaggerating?

This is also not the case.

The new developer might have been stating

1. The requirements are fixed
2. Ideal conditions
3. Based solely on their scope of work

the "pure implementation time."

This is also true.

If it were just about writing code, 5 days might be accurate.

The Problem is the Standard, Not the People

The real issue in this situation

is not who is right.

1. What standard was used for the estimate?
2. What risks were included?
3. How does it compare to similar past tasks?

The problem is the complete lack of visible grounds for these questions.

From a manager's perspective, there's no way to distinguish

between a "slow developer" and an "exaggerating developer."

Ultimately, they resort to gut feelings,

and those gut feelings almost always ruin the project.

What's Needed is Comparable Numbers

To reduce this confusion,

estimating development timelines requires at least the following:

1. Actual time spent on similar features in the past
2. Average deviation at the individual and team level
3. Ratio of design to implementation, review, and deployment
4. Impact of anticipated risks on the schedule

In other words,

instead of "This time it's 3 months" or "This time it's 5 days,"

everyone should be able to understand why that duration is estimated and how it compares to previous projects.

Development Timelines are a Matter of Data, Not Gut Feeling

Developers don't lie.

They simply speak from different perspectives.

The problem is

the lack of a common language and metrics to explain these differences,

and the burden always falls on the managers and the entire organization.

It's time

to ask "What can we use as a basis for judgment?"

rather than "Whom should we trust?"