The 'Almost Done' Fallacy in Software Engineering

Level 1: So Close, Yet So Far

Imagine you’re cleaning your room. You spend an hour picking up toys, stacking books, and making the bed. You look around and proudly tell your parents, “I’m almost done!” But then, as you start to wrap up, you notice all the little things that still need attention. There’s a whole pile of stuff shoved under the bed that needs sorting. The shelves are dusty and need wiping down. You still have to put the cleaning supplies away and take out the trash. Suddenly, that feeling of being almost finished disappears – there’s more work left than you thought! 😅

That’s exactly the point of this joke. In software development, saying “we’re almost done” is like thinking your room is almost clean when you’ve put away the big things but haven’t tackled the details. The “real work” – those last tasks that really complete the job – is still ahead. It’s funny because we’ve all felt that frustration of underestimating a task. Whether it’s cleaning a room, finishing a school project, or building a new app, the last bits often take a lot more time and effort than we expect. The meme uses this everyday feeling to make us laugh and nod in agreement, because “almost done” so often means not done yet at all.

Level 2: Beyond Code Complete

Aaron Levie’s tweet jokes that in building a software product, saying “we’re almost done” usually means there’s a lot of work still left. To a newer developer (or a hopeful project manager), almost done might sound like the project is basically finished, but veterans know it marks the start of a tough finishing phase. Why? Because writing the main code for features is just one part of the Software Development Life Cycle (SDLC). After the features seem “done,” a whole series of crucial steps remain. This includes tasks like:

• Testing (QA) – running the software in many ways to catch bugs and make sure everything works correctly on different devices, browsers, or scenarios. Often, Quality Assurance reveals unexpected problems that weren’t obvious during initial coding.
• Bug Fixing – addressing all the issues found during testing. Some bugs can be trivial, but others can be tricky and time-consuming to fix without breaking something else. There’s a common saying: “There’s always one more bug” – meaning even when you think you fixed them all, another often pops up.
• Performance Tuning – improving how fast or efficient the program runs. Maybe the app works, but under heavy load it slows down or crashes. Developers have to optimize code and database queries, which can involve deep changes.
• Documentation – writing instructions and documentation for users and other developers. This could be user manuals, API docs, or inline code comments. It’s important for maintainability and for onboarding others, but it takes careful effort.
• Polish and User Experience (UX) fixes – refining the small details: aligning the layout, smoothing animations, clarifying messages, making things look and feel professional. These finishing touches often uncover minor inconsistencies that need fixing (e.g., a button that isn’t quite in the right spot, or text that’s not clear).
• Deployment and Release Prep – preparing the software for release. This can involve packaging the app, configuring servers or cloud infrastructure, writing release notes, setting up monitoring, and ensuring you have a rollback plan if something goes wrong. It’s not as simple as hitting “compile” – there’s a lot of environment setup and checks to do.
• Stakeholder Review & Changes – showing the almost-finished product to stakeholders (like clients, managers, or users) often leads to last-minute feedback. Maybe a feature doesn’t exactly meet the client’s expectation or a compliance team needs changes. Incorporating this feedback can mean more development work even when you thought everything was completed.

All these steps are part of the invisible work after code complete. They’re “invisible” because, when you’re happily coding the main features, these tasks don’t show up as new features in the product. They happen behind the scenes, but they are absolutely necessary to go from a working code to a finished, shippable product.

This tweet is poking fun at how estimations are hard in software projects. People naturally underestimate how long things will take – a cognitive bias known as the planning fallacy. In a project, you might plan the coding tasks well, but forget to account for the “boring” things like testing and deployment, or just assume they’ll be quick. That’s why someone can cheerfully announce “We’re 90% done!” after the main features are coded, without realizing the remaining 10% of tasks will demand as much effort as everything so far. This is exactly the ninety-ninety rule expressed in humorous form. The first “90% done” often only covers the obvious work; the second “90%” emerges as all the subtle, difficult stuff that was overlooked.

In project management (especially Agile methodology), there’s even a concept of “Definition of Done.” This is a checklist a team agrees on for when a task or project is truly considered done. It usually includes not just “code written” but also “code reviewed,” “tests passed,” “documented,” and “deployed to staging” etc. The reason teams create a strict Definition of Done is to avoid this very trap – where a developer says “it’s done” meaning the code is written, but others hear “it’s done” and assume it’s ready for users. If the Definition of Done isn’t thorough, saying “done” too early creates false confidence.

The title quips about the “hardest sprint” still ahead. A sprint in Agile practice is a short, fixed-length period (like 1-2 weeks) where a team works to complete certain tasks. The joke is that when someone says almost done, it often actually means you need another full sprint (or more!) of intense work to truly finish. It’s tongue-in-cheek because the hardest sprint – filled with late-stage tasks under deadline pressure – tends to come right after everyone thought things were wrapping up. That final push is typically stressful: developers might be scrambling to meet a looming ProjectDeadline, managers are anxious, and everyone feels the DeadlinePressure.

In simpler terms, the tweet highlights a well-known developer reality: “Done” isn’t done until all the quality and delivery steps are finished. Just coding a feature isn’t the end. For someone new to software development, it’s an important lesson. The work that comes after writing the code (testing, fixing, refining, deploying) can take as much time – and sometimes more – than building the feature itself. That’s why seasoned engineers chuckle (or groan) when they hear “we’re almost done.” They’ve learned that line is often more optimistic than realistic, and a lot of unglamorous work is hiding just below the surface of that optimistic status update.

Level 3: 90% Done, 90% To Go

For experienced developers, this tweet rings painfully true. In software, “we’re almost done” often translates to “buckle up, the real work is just starting.” This is a nod to the infamous ninety-ninety rule: “The first 90% of the code accounts for 90% of the development time... the remaining 10% of the code accounts for another 90%.” 😓 In other words, when a project feels 90% done, you might still have 90% of the work left. The humor here comes from how ProjectManagement optimism collides with Developer reality. We’ve all seen DeadlinePressure lead someone to declare a project “almost done” to calm stakeholders, only to enter a grueling final phase of bug fixes, performance tuning, and last-minute changes. It’s practically an industry rite of passage – an inside joke shared with a knowing groan.

This meme highlights a common SDLC pitfall: the almost_done_fallacy. Teams celebrate being “code complete” on features, thinking the finish line is in sight, but discover a mountain of invisible work after code complete. It underscores the gap between RequirementsVsReality. Initial requirements often focus on core features, but reality demands polishing edges, handling corner cases, writing docs, and dealing with StakeholderExpectations (who inevitably ask, “Why isn’t it shipped yet if you’re almost done?”). The result is a frantic last sprint – late nights addressing everything that was glossed over. There’s a reason estimations_are_hard is practically a proverb in this field.

From a senior perspective, the tweet is TechHumor born of hard-earned wisdom. It satirizes the chronic underestimation baked into software timelines. We know by now that testing, QA, and deployment always take longer than planned – it’s practically Hofstadter’s Law in action (“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”). Yet, due to optimism or UnrealisticDeadlines set by higher-ups, teams keep falling into the same trap. The release_readiness_myth persists: everyone acts like “code complete” means the product is ready to ship, ignoring the gauntlet of final integration tests, user acceptance feedback, and last-minute polish. Seasoned devs share a dark chuckle at this because they’ve survived that final 10% deathmarch before – pulling extra hours in crunch mode while the project manager’s “we’re almost done” echoes mockingly. It’s a DeveloperPainPoints meme that pokes fun at how the software world consistently treats the last mile of a project as an afterthought, even though that last mile often feels like an endless marathon.

Translation for the battle-scarred: hearing “almost done” in a project meeting is like hearing the starter pistol for a hardest sprint ahead. You mentally reschedule your evenings and stock up on coffee, because you’ve learned that “done” is a mirage until the app is actually in production, all bugs squashed and docs written. The tweet captures that ironic truth: in software, “almost done” means the real grind is about to begin. It’s funny because it’s true – and a little terrifying because we keep proving it true release after release.