Today, I want to discuss a sensitive topic — time estimates for software projects. This issue significantly impacts engineers of all kinds who are constantly asked to provide estimates, as well as managers planning work and budgets. The problems with estimations are valid for any technology — no-code, low-code, off-the-shelf software integration, and custom software development as the most complex kind of project.
In my career, I’ve seen this from all sides. I worked as an engineer for years, trying to estimate accurately and meet deadlines. I managed engineers and aimed to help them do the same. I also represented clients, requesting vendor estimates and ensuring they were timely delivered.
Reliably estimating software timelines is impossible. If you’ve built the exact same thing before, maybe. But why redo the same work? Anything even slightly new means estimates will likely be missed.
This software uncertainty creates problems for everyone. It pressures engineers with constant deadlines. It strains project managers caught between engineers and stakeholders. It handicaps businesses unable to predict timelines and costs.
Changing the technology doesn’t affect the problem. You may buy a SaaS rather than build. But until purchased, you can’t foresee issues integrating it. The unknowns equal building it yourself — the earlier the project stage, the less you know.
This is true even for no-code tools. While projects stay small, mistakes cause less pain, but as the project evolves, deadlines start slipping due to the sheer complexity of the task.
I’ve seen similar unpredictability in other industries. I built a modular home a while ago, hoping to minimize surprises. The pre-fabricated modules were supposed to arrive on a set schedule for assembly. The scope was well-defined.
Yet things went differently than planned, despite vendors having done it hundreds of times. After buying the land, I learned building on a steep slope brought massive headaches: deep trenches for sewage pipes, trucks struggling uphill with heavy modules, and cranes barely reaching the foundation.
Each step before, during, and after construction hit problems affecting timelines and budget. Even pre-fab homes, which I thought predictable, faced issues. I can’t imagine the pain of custom homes, some DIY-ed for years. Despite the money spent, projects rarely finish on time — you can’t buy predictability.
The Allure of Estimates
Is there any solution to this? Use story points? Spend more time on requirements and planning? Dedicate resources to estimating? Play planning poker?
Unfortunately, estimates will always be guesses. The reality is unpredictable: any work, regardless of technology, will take an unknown amount of time. Even no-code projects labeled “quick” or “simple” repeatedly drag on.
The only solution is to mitigate risk with small steps. Agile exists because big, detailed plans fail. After excessive requirements gathering, finished projects still needed rework.
Estimation Methods Don’t Increase Accuracy
Over the years, I’ve tried many estimation techniques meant to increase accuracy. Planning poker, story points, ideal days, t-shirt sizing — you name it. While those methods provide a shared vocabulary, the resulting estimates remain guesses.
I once spent weeks on a detailed requirements document for a client’s custom e-commerce platform. We estimated 6 months based on functionality. 2 years later, the project was still ongoing. Constantly evolving requirements and technology changes made the original estimate pointless.
Even with Agile, breaking projects into smaller chunks doesn’t guarantee predictability. I remember a 2-week sprint that planned 3 moderate-scope user stories. By the end, partially completed stories were pushed to the next sprint. This scenario repeated until we reduced the scope.
You can’t accurately predict the future based on the present. New technologies and techniques emerge constantly in software. Unknown roadblocks appear. Customer needs change. The more innovative the project, the harder it is to estimate.
Leadership, Transparency and Adaptability
Since accurate estimates still need to be discovered, success requires engineering and business leadership.
Engineers should provide estimates in good faith based on current knowledge but avoid pressure to commit to unrealistic deadlines. Be transparent about uncertainty early in projects.
Managers should lead with empathy, avoiding rigid timelines. Prioritize regular check-ins to reassess progress and adapt scope or resources. Celebrate small wins, not just final delivery.
For the business, the priority is agility. Work in small, iterative phases. Use minimum viable products to get customer feedback quickly. Add runway to account for surprises. Ruthlessly prioritize must-have features, cutting non-essentials when needed.
With the right processes, reasonable estimates can be achieved. However, acknowledging inherent uncertainty and embracing transparency is vital. Customers will understand if you underpromise and overdeliver.
My Costly Modular House Example
I recently learned this lesson firsthand. As I told you before, I built a modular house to save time and money. I estimated I could get everything planned, delivered, and assembled in just 3 months.
What went wrong? Lots of minor issues added up:
- Making design changes
- Digging deeper than expected for foundation
- Hitting hidden pipes
- Weather delays
- A complete halt because the underground cable was discovered
Ultimately, I spent 50% over my initial budget between materials and rentals. My friends joked that I could have had a completely custom house built in the time it took me (which I doubt). But at least I gained a new respect for the unpredictability of any project, big or small, in any industry.
The key is being flexible. With software projects, aim for minimum viable launches first. Deliver iteratively and gain real-world feedback. Adapt plans when reality deviates from estimates. Be transparent with stakeholders when roadblocks occur.
While we can’t achieve perfect predictions, we can build great products through solid leadership, open communication, and embracing uncertainty as a given.
Originally published on Medium.com
