W.

Why Software Projects Miss Deadlines: The Known and the Unknown

By In Technology

Software development deadlines. They haunt our dreams, ruin our weekends, and yet, somehow, we’re always shocked when we miss them. From tiny web projects to colossal AAA games, the software industry has an infamously bad reputation for blowing past deadlines and budgets. But how do software engineers manage to be worse than, say, the folks who bid on highway systems?

The Known Unknowns: We Sort of Know What We’re Dealing With

Before we tackle the real villain, let’s touch on the “known unknowns.” These are the things we anticipate will pose questions or challenges. When a project kicks off, developers huddle with domain experts to map out the grand plan. This early phase is rife with questions:

  1. Architectural Trade-offs: “Should we use Framework X for rapid development? Will it scale if our user base explodes?”
  2. Technical Feasibility: “Is there a library that does what we need? Do we have to build it from scratch?”
  3. Project Management Triangle: “Do we write quick-and-dirty code now, knowing we’ll refactor later, or aim for scalability and security from the get-go?”

These questions are predictable and somewhat manageable. We know they’ll pop up and can plan (read: guesstimate) for them. But then come the…

Unknown Unknowns

Unknown unknowns are the sneaky, unpredictable gremlins that can throw a project into chaos. They are the reason even the most detailed plans can blow up spectacularly.

Examples of Unknown Unknowns

So, what do these elusive unknown unknowns look like in practice? Here are a few examples:

  • The Market/Product Changes: This is the most common. When you’re building software you are building it for an end user with a purpose in mind. But you can never know FOR SURE that you’re building the right thing. You will only really know what needs to change when you first watch a user play with it. That’s why it’s so important to get it into the hands of real users as quickly as possible.
  • Emerging Technology Changes: A new version of a critical framework or library is released midway through your project, rendering your current approach obsolete.
  • Unforeseen Integration Issues: An external API you depend on changes or is deprecated without warning, requiring significant rework. This literally happened to me this week, and I spent two days fixing a problem that worked the first time with the old API. And this was a tiny python script and a Make.com workflow… not some giant HIPAA compliant stack that has five engineers working on it. That kind of change could mess up a project by months.
  • Unexpected User Behavior: During testing, users interact with your software in completely unanticipated ways, uncovering bugs and usability issues that require substantial fixes. Think of yourself as an explorer here; learning new ways your system can be used, and how users can f*@&k it up.
  • Regulatory Changes: New laws or industry regulations come into effect, necessitating changes to your software to remain compliant.
  • Team Changes: Key team members leave the project, taking with them critical knowledge and slowing down progress as new members are onboarded.

The Exploratory Nature of Software Development

Software development often feels like your are Indiana Jones navigating a jungle with a half-baked map. Sure, you have a rough idea of where you’re going, but the terrain can change unexpectedly. When developers estimate how long a task will take, they’re picturing a perfect world scenario. It’s tough to convey to managers or clients—who often see programming as a kind of magic—why one feature is a cakewalk and another is a nightmare.

Agile vs. Waterfall: Why Flexibility Matters

This is why traditional waterfall methodologies, which demand every detail be nailed down upfront, often fail in software development. Designing everything on paper without accounting for unforeseen problems is a recipe for disaster. Agile methodologies, with their iterative and flexible nature, help mitigate the chaos of unknown unknowns by allowing for continuous reassessment and adaptation.

Agile is by no means perfect though. Agile projects fail for different reasons: scope creep, running out of budget, not being disciplined in prioritizing features, not launching quick enough, over-engineering, and plain old building bad software.

The Myth of Big Design Up Front

Big design upfront (BDUF) robs software of its most powerful trait: adaptability. The ability to iterate, update, and improve on the fly is crucial. Agile approaches embrace this, understanding that no one can predict every challenge. The flexibility to pivot based on real-world feedback and emerging obstacles is what keeps projects on track—relatively speaking.

Making Software Development More Predictable

While we can’t eliminate all the unknowns, there are strategies to make software development more predictable. The problem is that most of this stuff makes you slow down. There is always a trade off. So enjoy!

  1. LAUCH EARLY AND OFTEN: Get your system into the hands of real users as soon as possible. If you’re not embarrassed to let users play with it, you’ve launched too late. I just wrote about this.
  2. Adopt Agile Methodologies: Agile frameworks like Scrum and Kanban promote iterative development, continuous feedback, and flexibility, making it easier to adapt to changes and unforeseen issues.
  3. Frequent Check-ins and Reviews: Regularly scheduled reviews, stand-ups, and retrospectives help catch issues early, before they spiral out of control.
  4. Automated Testing: Implement a robust suite of automated tests to catch regressions and integration issues early in the development process.
  5. Continuous Integration/Continuous Deployment (CI/CD): Use CI/CD pipelines to automate the deployment process, ensuring that new code integrates smoothly with existing systems.
  6. Risk Management: Proactively identify potential risks and develop contingency plans to address them if they arise.
  7. Maintain a Flexible Architecture: Design systems with modularity and scalability in mind, allowing easier adjustments as requirements evolve.
  8. Clear Documentation: Ensure comprehensive and up-to-date documentation so that new team members can quickly get up to speed and existing members can easily reference past decisions.
  9. Cross-Training Team Members: Promote knowledge sharing and cross-training within the team to prevent project delays if someone leaves or is unavailable.

Embrace the SOME of the Chaos

Software development is messy, unpredictable, and often maddening. But by recognizing the difference between known unknowns and unknown unknowns, and embracing methodologies that allow for flexibility, we can navigate the chaos more effectively. Next time a deadline whooshes by, remember: it’s not (just) about poor planning. It’s about the nature of the beast itself.

In the end, the key to handling software project deadlines is accepting that some things will always be out of our control. So, let’s embrace SOME of the chaos, adapt on the fly, and maybe, just maybe, we’ll get a bit closer to hitting that elusive target. And if not, there’s always more tea, whiskey and a good sense of humor to see us through. Although that will never make your boss our your client happy.

Previous ArticleNext Article
I help companies turn their technical ideas into reality.

CEO @Sourcetoad and @OnDeck

Founder of Thankscrate and Data and Sons

Author of Herding Cats and Coders

Fan of judo, squash, whiskey, aggressive inline, and temperamental British sports cars.

Leave a Reply

The Internet Doesn’t Have Enough Love In It (And How We Can Fix It Easily)

In Technology

I’ve been thinking about all the wrong things when it comes to AI writing code.

Everyone else seems to be too. Job displacement. Security vulnerabilities. The ten-times-faster developer who now bills the same and delivers four times as much. These are real conversations worth having, just not the one I want to have right now.

The one I want to have is about teaching a six-year-old multiplication.

Here’s what I mean. Imagine you’ve been sitting with your kid every night for two weeks trying to explain multiplication. You’ve tried drawing rows of dots. You’ve tried songs (don’t judge me). You’ve tried the “just think of it as groups of things” approach that works for literally every other math concept but, mysteriously, not for your kid. Then one night, something clicks. You found the explanation, YOUR explanation, the one that worked for your actual kid with your actual kid’s brain, and it finally, beautifully, clicks.

Now imagine you could spend a Saturday morning turning that into a small web app. Not a startup. Not a SaaS platform. No login. No backend. No one’s going to hack it (there’s nothing to hack). Just a little thing that walks through multiplication the exact way you figured out it works, step by step, the way you’d explain it. You send it to the WhatsApp group for your kid’s class. Some of those other parents, also quietly losing their minds over multiplication, try it. And it helps.

You just made the world a tiny bit better. That’s it. That’s the whole thing.

Claude Code exists now, and a handful of other tools like it, and the reason I think this matters isn’t productivity. It’s access. The barrier between “I have an idea for something that could help people” and “I have a thing that helps people” used to require knowing how to code, or hiring someone who does, or talking a developer friend into your project over enough beers that their guilt exceeded their better judgment. Now it’s a Saturday morning and a good description of what you want to build.

The internet already has beautiful things in it that were built out of love. Free coding education for kids. Open-source video editors. Someone’s incredibly detailed home-brewing app with no monetization plan whatsoever. Artists making interactive experiences because they wanted to see if they could. These things exist because someone cared more about making the thing than making money from the thing. I think that ratio is about to shift dramatically in favor of the people who just want to make something good.

I’m not saying we should all stop paying for Salesforce (we should probably keep paying for Salesforce, there’s a reason that thing costs what it costs). I’m saying the category of software that was previously not worth building because it wasn’t commercial enough to justify the cost, that category just got a lot more interesting.

What’s in that category? Things like:

  • An app that helps beginning judo students understand the concepts behind a throw, not just the mechanics, because judo is where I learned confidence and discipline and I want other kids to find that
  • A private family memory vault (not Instagram, not Facebook, not anything with an algorithm deciding what matters), just a place where the people who love my son can send photos and stories somewhere safe, for him to open when he’s older (Maybe I’ll turn this into something?)
  • A system that reminds companies to send their employees gifts on the days that actually matter to them, because I know from running a company that it fills the cup of the person giving just as much as the person receiving (Thankscrate, if you’re curious, and yes, that one is turning into something real, but that is genuinely not why I built it)

None of those were commercial ideas first. They were just things I cared about.

I think the most interesting software that gets built in the next few years won’t come from developers moving faster. It’ll come from people who previously had no path from “I care about this” to “I built something about this,” and now they do. Parents. Coaches. Teachers. The person in your office who could explain that one complicated process better than anyone and has always secretly wanted to turn it into something.

The stakes are low. The bar to launch is low. The cost is low. The only thing required is that you actually give a damn about what you’re building.

So… What do you give a damn about?

Go build it. I still sometimes have to count on my fingers, but I’m told the app helps.