I just read an article on heise where the Standish Group’s CHAOS Report from 2020 was mentioned. The findings were … sobering: only 31% of software projects succeed — meaning they are delivered on time, within budget, and provide real value to users or customers. The remaining 69%? Half of them struggle with significant issues like budget overruns or scope creep, while 19% fail completely, consuming resources without delivering anything useful.
31% … Less than 1/3! That’s a really poor success rate, a big risk — and obviously, it’s reality!
The Problem with “All-or-Nothing” Projects
It reminds me so much of several little applications that we as a team often wrote just for ourselfes. Like some maintenance automation or web frontends to make our lifes easier. Those applications usually grow over the years. A quick addon here, a quick feature there, sometimes just quick & dirty due to several reasons.
And at some point, people realize that it’s a bit messy. Nothing anybody is proud of but it’s just the way it is.
In these situations, someone inevitably suggests, “Let’s just quickly rewrite it from scratch!”. My response is usually the same: No. Because with the odds of success being as low as 31%, I’m not eager to gamble.
Of course this leads to discussions as it seemed like I distrust the team (which I don’t). But I usually ask some questions, like:
- Do we know exactly, what actual features we REALLY need and how they are interconnected?
- How quickly can we rewrite it?
- When business priority changes at 70% completion … what do we do? Can we say “no, we need to finish rewriting this first?”, “do we have to operate both versions in parallel then?”
- …
Usually people quickly see the risk and we opted for iterative improvements.
Why I prefer Iterative Improvement
With iterative development, there’s no need for a “big bang” release that either succeeds or fails spectacularly. Instead, the application remains functional throughout the process. Small, incremental updates ensure that the system is always in a usable state, even if not every feature is perfect. This approach minimizes downtime and reduces the risk of catastrophic failure.
Smaller updates are easier to manage, test, and review. When changes are incremental, it’s simpler to identify and fix issues before they escalate. If something goes wrong, the impact is contained, and the team can quickly revert or adjust.
Actually it embraces the principle of failing fast. If a change doesn’t work as intended, we can take corrective action immediately before significant resources are wasted.
Also, business priorities shift over time. An iterative approach allows to respond fast without putting everything on hold without getting any benefit from the time invested.
The Downside of Continuous Evolution
Of course, continuous evolution isn’t a silver bullet!
It can take longer to achieve the same results compared to a complete rewrite. The process requires patience, as improvements are made incrementally rather than all at once.
But: you can stop at any time. If priorities change you’re not left with a half-finished project that delivers no value. Instead, you have a functional system that still delivers value. And the next refactoring tasks can be taken up later.
No One-Size-Fits-All Solution
I want to be clear: this isn’t a universal solution. Sometimes, “all-in” projects are necessary due to reasons.
In such cases, a big (re)write might be the only viable option. However, if there’s a choice, the risks are smaller with evolution rather than revolution.
Leave a Reply