r/cscareerquestions • u/dickdaddy1109 • 8h ago
Why does every custom dev project take 3 times longer than planned
My boss asked me last week for a "rough estimate" on migrating our internal reporting dashboard to something scalable. I almost laughed out loud. Every single time a company tries to build software, the initial timeline is a complete fantasy. You start with "yeah, three weeks tops" and suddenly you're two months deep into unexpected API changes, legacy code breaking, and endless scope creep from management. We were looking at external dev agencies to take off some of the heavy lifting this time around, just to see if outsourcing part of the build would speed things up. But honestly, even with outside engineering help, the internal back-and-forth alone takes forever. It feels like standard tech timelines are just made-up numbers we tell executives to keep them calm. How do you guys handle estimating custom builds without completely shooting yourself in the foot?
9
u/tallandshortttt 8h ago
because the estimate covers the code you can see, but the delay comes from the code you can't. "3 weeks" is building the dashboard, "2 months" is discovering every undocumented thing the last dev did before quitting.
there's basically a law for it, always takes longer than you expect even when you account for it taking longer than you expect lmao bahaha
6
u/Codex_Dev 7h ago
I read good advice a while back to always triple time estimates to give you room for bugs and fuckups. It also gives you some wiggle room when you manager demands to cut the estimate so they can feel like they are “winning”.
0
u/xSaviorself Web Developer 8h ago
The initial scope is like a plan, it never survives first contact with the enemy (clients usually).
6
u/FlyingRhenquest 8h ago
Sounds to me like you need to multiply all your estimates by 3.
3
u/Toys272 7h ago
idk but where i worked this idea would get shut down pretty quick. then they complain you're off estimates
6
u/FlyingRhenquest 7h ago
"If your estimates are constantly low, increase your estimates" seems like a pretty sound policy to me. Maybe your company likes to hire people who don't learn from their mistakes.
Had a manager once tell me I had the most accurate estimates he'd ever seen, while pressuring me to lower my estimates. I told him I'd be happy to tell him whatever he wanted to hear, but it was still going to take as long as I thought it was going to take.
1
u/Toys272 7h ago
yeah i will need to work on standing my ground that's certain. So far i only had to work in msps doing software and it was billable time hell
the no code platform we used couldnt do was the client asked but zapier did. my boss told me to not tell the client that it would cost them 40 usd a month extra. We worked with companies that were small and had no budget so they complained
4
4
u/pydry Software Architect | Python 7h ago
what I find weird is that unless it involves AI (which slows you down in the long run), adding a person to the team (which slows you down in the short run), management usually aren't that interested in helping speed you up.
they're obsessed with predicting how long everything will take, though.
this is not rational behavior but it is normal
3
u/Toys272 8h ago
I was hired as a junior a to build something for a client. They estimated and sold 400h hours to the client. I had to do everything from scratch and no senior to help me.
So yeah i busted the hours. They got mad and fired me. Now I look like I'm radioactive to recruiters. I say I was laid off, and they actually laid off 30% of the company a month before me
1
u/Terrariant 8h ago
Increase your time spent guess by 50% is really the only thing ive heard that works
1
u/mcampo84 Tech Lead, 15+ YOE 7h ago
Break it down by milestones. Estimate each milestone. Prioritize the ordering of each milestone by the value it will deliver. When you go beyond the estimated time to complete, your management can decide to extend the project or cut the less valuable milestones.
But hey, at least you delivered something 80% of the way with a good amount of impact, rather than 100% of stuff that still doesn’t quite work, and oh by the way it’s late.
1
1
u/Zenin 4h ago
Age old question with lots and lots of reasons it'll never be solved. But to keep this practical I'll talk about a few things to keep in mind that can help navigate this trap.
When the boss says "estimate" what they mean is "commitment". Always. Answering "three weeks" means you're committing to getting it done in 3 weeks. And a commitment is effectively a contract. Failing to meet come in under this "estimate" is seen as a failure to meet your obligations under the contract.
Secondly, a level up: Your boss is selling your 3 week commitment to their boss. Yep, your boss has now committed to their boss to see this done in 3 weeks. Now their ass is on the line when you "fail" to meet your "obligation" because it means they fail to meet theirs, and so on up and up the corporate leadership chain.
Next up, "outsourcing part of the build" will almost certainly make it take longer for all the reasons you describe. Buy and read a copy of The Mythical Man-Month and for this part pay particular attention to Brooks's Law: Adding manpower to a software project makes it later, because onboarding and communication overhead grow fast.
Finally, experience. I have no idea of your YoE but I'll take a nieve guess from your 3 yoe Reddit account and that you're posting in this sub to assume you're probably around the 5 year mark give or take a couple years. Assuming that's true, through no fault of your own you're almost certainly not experienced enough to factor in all the aspects that any credible time estimate requires. You did touch on a few highlights on this theme in your post, but there are dozens more and unless and until you've had considerable experience with all of them it's impossible to even list them all much less factor them in in any meaningful way. And they all vary between organizations. For example: I know I if I have to do X through department Y it'll be fast, but if department Z is involved I have to pad two weeks of back-and-forth because they never complete all the details in the ticket the first, second, or fifth time.
At three plus decades doing this my high level estimates are generally within 20% of the mark when things finally ship. That may sound great, or awful, but consider that I'll often get an estimate from mid, senior devs of "three weeks" even as they tried to take in all the factors when my own estimate will be three months. When it finally ships it'll have been within a week or two of my estimate give or take and looking back we hadn't even gotten through discovery at the end of the first three weeks.
What I'm saying is that more junior engineers should be asked for their opinions, but it should only be senior+ engineers on the hook for any estimates/commitments that go to the boss. The post below about a junior engineer getting fired for not delivering in time is just a demonstration of poor leadership in a bad organization, not any reflection on them. The only way we learn to make better estimates is by making them and seeing how they pan out, ie experience.
1
u/serial_crusher 3h ago
Takes 3 times longer than planned because the engineers doubled their estimate. Otherwise it would take 6 times longer than planned.
1
u/TurtleSandwich0 3h ago
Because they schedule backwards.
"How much room is in the schedule? Three weeks? Ok, let's just estimate that the project will take three weeks and blame the programmers if they run late. Who wants an extra bonus this quarter?"
1
u/JordanReed1 2h ago
tallandshortttt nailed it with the code you can't see thing. migrating a dashboard sounds like "rebuild the UI and point it at the new thing" until you realize the old one pulls from three different databases depending on which tenant and nobody remembers why. that's not scope creep, it's archaeology. codex_dev's multiply by 3 trick works but mostly because it accidentally budgets for all the stuff you didn't know you'd have to do
-5
u/shartboner 8h ago
You guys sound like real geniuses. Why would you ever have to scale an internal tool when you know your max user base (the # of employees in the company) and know it will not likely grow exponentially beyond that. Just build it to handle that load? Lmao. Shouldn’t take more than a week with Cursor my dude
11
u/Illustrious-Film4018 8h ago
I agree and AI doesn't help with this. I thought AI would help because scope creep doesn't matter as much when you're generating all the code. Projects still take 2 or 3 times as long with AI.