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 squash, whiskey, aggressive inline, and temperamental British sports cars.

Leave a Reply

Is Anyone Working on Agentic Authentication?

Everyone is building AI-powered tools, even people who shouldn’t be. Agents seem to be the next obvious (and big?) step. But these little bots need a secure way to act on behalf of users without causing chaos.

Richard Dulude at Underscore VC wrote about the lack of identity standards for AI agents in this LinkedIn article. I don’t know Richard or Underscore VC (sorry). But, he’s right, traditional authentication assumes either a human or a machine with static credentials, and that doesn’t work for AI agents that need to make decisions and take actions. Companies want accountability (and probably liability), and users need control of what their potentially psychedelic robot is doing on their behalf. This balance doesn’t exist yet.

This is probably for another blog post, but right now, everyone, including the bots, are using human interfaces as a stopgap. OpenAI’s Operator is a great example, agents pretending to be humans to interact with systems that weren’t built for them. That’s fine for now, but eventually, the human interfaces will be an afterthought. Like how “mobile-first” design took over, we’ll be doing “agent-first” design with human-accessible backups. Having a dedicated standard for agentic authentication might be a good first step in that machine-to-machine way of thinking and designing systems.

Agentic Proxy Credentials (APC): A Solution (A Term I Totally Made Up)

I made this up. It’s probably a bad term, but naming things is fun. This doesn’t exist… if you are a large battery and power supply company, don’t sue me. I’m spitballing here.

One possible fix is the “sucked out of my thumb” Agentic Proxy Credentials (APC). This would let users grant their AI agents secure, limited permissions to interact with systems while making sure the right level of oversight are in place. There are things that I wanted to do this very week, but I don’t trust my bots with my actual usernames and passwords:

Stop me talking to Airline Idiot Bots

Talking to airline chatbots is painful. Right now, they can only regurgitate FAQ answers. With an APC, my AI assistant could log into my airline account, check flights based on my loyalty status, and rebook me without you having to touch anything. This would make AI actually useful instead of just a slightly smarter help page.

Paying for small things without having to deal with entering my ACH data AGAIN

I don’t want to give an AI full access to my bank account. But I wouldn’t mind letting it handle small transactions in a controlled way. With APCs, I could grant my assistant time-limited access to approve payments or move money within strict limits. The AI does the work, I stay in control, and my bank account doesn’t mysteriously empty overnight… unless I’m Ambien shopping again.

AI Dungeon Master’s Assistant

D&D is great, but session prep is a time sink. I want an AI that logs into my D&D Beyond account, manages stat blocks, generates lore-friendly content, and even takes session notes. The AI handles the boring admin work, and you get to focus on making your players cry (or cheer, if you’re nice). Yes, serious stuff here.

How It Could Work

There are a few ways to make this happen, I think. I’m no longer allowed to do actual engineering at my own companies I founded, so this blog is my outlet. Everyone needs a hobby.

Is Someone Already Building This?

Honestly, I wouldn’t be surprised if Okta, OAuth, or OpenAI are already working on this and I’m just ranting for no reason. But if they aren’t, they should be. The pieces are all there, someone just has to put them together.

I need this, but I can’t find it. If anyone is working on it, let me know. I’m too busy trying to solve employee gifting at scale at Thankscrate, implementing AI into every existing business at Sourcetoad, and making sure passengers can watch TV and book dinner reservations in the middle of nowhere at OnDeck.