One of the most common questions developers get is:
“How much will it cost?”
It's a reasonable question.
The problem is when it is asked before anyone has properly explained what needs to be solved.
A developer can't give you a useful estimate for a problem they don't understand.
At best, you'll get a guess.
At worst, you'll get a number that everyone later regrets.
“How much will it cost?” isn't enough
Imagine someone says:
“We need to improve our customer portal. How much?”
That's not really a software requirement.
What is wrong with the portal?
Is it slow?
Are customers unable to complete certain actions?
Is the interface confusing?
Is the underlying system difficult to maintain?
Are there security concerns?
Does it need to connect to another system?
Each of those problems could require a completely different solution.
The cost could vary significantly.
The same problem can have very different solutions
Suppose a company says:
“Our reporting system is too slow.”
One possible answer is to optimise a few database queries.
Another might be to change how reports are generated.
Another might be to redesign the reporting architecture.
And in some cases, the reporting system itself may need to be replaced.
You cannot responsibly estimate those options from one sentence.
First understand the problem.
Then decide what needs to be done.
Then estimate it.
A good estimate starts with questions
Before discussing cost, a good engineer should want to know things like:
What is happening today?
What isn't working?
Who is affected?
How often does it happen?
What happens when it goes wrong?
What systems are involved?
What has already been tried?
What would a successful outcome look like?
These questions aren't delaying the project.
They are reducing uncertainty.
Estimates are not promises
Even after understanding the problem, software estimates are still estimates.
There will always be unknowns.
The important thing is to make those unknowns visible.
For example:
Known: We need to add a new approval step.
Unknown: The existing workflow may have several hidden dependencies.
That's much more useful than simply saying:
“It will take three weeks.”
A good estimate explains what the number is based on.
Beware of suspiciously precise numbers
If someone gives you a very precise estimate before looking at the system, be careful.
“Exactly 17 days” sounds confident.
It doesn't necessarily mean it is accurate.
Software work has uncertainty.
A responsible team should be able to explain what they know, what they don't know and what might change the estimate.
Start with the problem
Instead of asking:
“How much will this feature cost?”
Start with:
“Here's the problem we're trying to solve.”
Then let the engineering team investigate the possible solutions.
You may discover that the original idea isn't necessary.
You may find a much smaller solution.
Or you may confirm that a larger project really is justified.
Either way, you'll be making a decision based on something more useful than a number pulled from thin air.