It’ll Take 2 Weeks... Ish

Last week, an acquaintance pinged me for a quick quote on a software task.

I asked a few clarifying questions. Nodded sagely. Squinted at the ceiling like a wise old monk. Then gave him a ballpark estimate.

Calm. Confident. Channeling my inner Mahesh Babu / Vijay / Salman Khan - Ek baar jo maine commitment kar di, uske baad toh main khud ki bhi nahi sunta. ["Once I’ve made a commitment, I don’t even listen to myself."]

Then, just to validate, I posed the same question to the team.

Cue confusion. Chaos. And a mild existential crisis.

Some estimates were lower than mine. Some were higher. Some were wildly optimistic — like launching a spaceship with a pressure cooker. A few had solid reasoning. A few sounded like they were made during REM sleep.And somewhere in the middle of this spreadsheet storm, I could hear a silent chorus from the team:"Enthina Ee Pani." ["Why are we even doing this?"]

That perfect blend of disbelief, amusement, and the quiet wisdom of people who’ve been burned by “simple change request” before.

And that’s when it hit me (again): Project estimation in software is not a science. It’s barely an art. It’s a calibrated guess dipped in optimism and sprinkled with trauma.

We learn from past misses. We build buffers. We still get it wrong sometimes.

But slowly, steadily, our guesses get... less wrong.

So no, we may never perfect estimation. But we can definitely finetune it - with every project, every team debate, and every moment we mutter, "Ab bol hi diya hai toh dekh lenge." ["Now that we have committed, we will figure it out"]

Or, as Thalaivar wisely declared, "Oru thadava sonna, nooru thadava sonna mathiri." ["If I say it once, it's as good as saying it a hundred times."]

Especially helpful when repeating the same delivery timeline for the fifth review call.

Okay, But Can We Standardize It?

You can’t eliminate the chaos. But you can politely ask it to wait outside the sprint planning meeting.

Here’s what helps:

1. Start with crystal-clear requirements
Easier said than done. Most clients start with “simple app” and end with “I want it to work like Uber plus Google Maps plus Duolingo.” Tools like Replit or low-code prototypes help translate vague dreams into clickable reality.

2. Treat changes as separate tasks.
Whether you charge for them or not is your business call. But acknowledge them. Track them. Log them. Because “just one small change” is how every horror story begins.

3. Build a component library.
If your team has built login flows 17 times, stop estimating them from scratch. Document how long they typically take. Better yet — have reusable components built for the standard stuff. Save your creativity for the 2 AM production bugs, not the login screen.

4. Use estimation templates by project type.
E-commerce is not the same beast as a SaaS platform or an internal dashboard. Different beasts, different buffers. Don’t mix breeds.

5. Estimate in ranges, not absolutes.
"3 to 5 weeks" gives breathing room. "Exactly 21 days" gives anxiety. Add buffers. Then buffer the buffers. We call it the Murphy Margin.

6. Add a confidence score.
A low-confidence estimate means there are still open questions. A high-confidence one means either you’ve done this before or you’ve severely overestimated your caffeine supply.

7. Involve multiple viewpoints.
Developer. Tester. Designer. Tech lead. One sees effort. One sees edge cases. One sees user rage. One sees the big picture. Get all of them in the room before you quote.

8. Write down your assumptions.
"Client will provide assets" "API will have docs" "No new stakeholders will appear mid-project and casually say ‘change the UI, na?’" Spoiler: They will. His name will be [NAME REDACTED]

9. Retrospect. Then move on.
After each project, check the gap between estimate and reality. Celebrate the wins. Analyze the misses. Learn. And then move on with a smile and the wisdom of Kurupp: "Eda Mone… Happy alle?" ["My dear boy… you happy or what?"]

The Point of Estimation

Project estimation in software is a delicate mix of optimism, experience, negotiation, and divine grace. You’ll get it wrong sometimes. That’s okay.

The goal is to be less wrong each time.

And here’s the thing - you still need the estimate.

Even if the path changes, you need to know where you started. Without a plan, you won’t know how far off you are or if you’re off at all.

It’s not about being rigid.

It’s about having a direction, so course correction actually means something.

Estimation is not a guarantee. It’s a compass.

And when in doubt, remember:

"Picture abhi baaki hai, mere dost."
["The story isn't over yet, my friend."]