
By A. Malthe Henriksen
-
May 5. 2025
Ever since the introduction of the agile manifesto and lean software methodologies such as scrum we've seen a surge of powerful applications built be fewer people than ever before. There's no denying it, amidst the countless startups and well-established enterprises, those who succeed are those who have adapted to the modern world of development practices. Of which, no methodology is more prevalent than SCRUM.
Unfortunately this happens to coincide with software being more buggy than ever. Is this a coincidence? Probably. But I would be lying if I said I didn't think part of the modern development culture wasn't at fault for producing code was "good enough" to ship.
The 80-20 rule states that 80% of the value comes from 20% of the features and as such, the rest is left to crumble as the pile of shit on top of it grows.
You see - in SCRUM the basic workflow is as such; we have backlog of all the stuff we want to build. This slowly accumulates over time, either from user feedback or fed from a product managers fever dream after attending a next-generation technology conference, where he spotted great candidates for the "opportunity solution tree".
All the features we want to implement and deliver to our users are then ranked in order of importance, and haphazardly slotted into a 2-4 week work slot and neatly tied with a bow.
The issue is that everyone knows the 80-20 rule, and this is a philosophy the product manager lives by. I can't count how many times I have discussed a feature, where we inevitably end up at a point where the developers agree to reduce their estimates in order to deliver a minimally viable version of the feature.
Maybe it's a rework in design or maybe it's testing. There's always something that will get cut in the agreement just "gauge user response" or "have it live a little before committing". And before you know it the entire application is a collection of minimally viable features that are tied together with promises of a better future, where well get time to fix the obvious bugs and introduce testing once we have made it past the release deadline - Don't mind the roadmap only has features that are at least as complex as the one we just agreed to make, that's just a detail.
It's seldom the intention of product management to revisit or reap the value from the feedback of the feature if the initial iteration delivers the 80%. And the sad reality is that this is the responsible path forward - from a business perspective at least.
The constant tug of war between the engineers and product management is precisely what drives many companies to win in the marketplace. After all, the goal is not to make great software - it's to make money.
It's tough to sell 'better performance' or 'stronger security' when it's not really what sells the product. Unfortunately a lot of software is still being released with known vulnerabilities. Do you really think the entirety of a release cycle is knocked off-course become some and rare edge-case had has been discovered that could potentially cause data corruption by a malicious actor? Well, if you do, I envy you.
Do you think the reason why Windows 8 decided to swap out the the desktop environment with the sleek start menu, that also worked for smart-devices was because it would make their product better? Probably not. The intent was to streamline it, making it a bit worse for the expert user and good enough for the lowest common demoninator.
So what can we do? As consumers we can make sure our hard-earned money is well spent, and we jump ship when the products we use take a turn for the worse. Luckily this worked for the Windows 8 release, which was a drastic departure from the prior release of windows.
As developers however we must learn to deal with the fact that we might be responsible for bad software or carry out bad software decisions beyond our control. We must learn to include necessities such as testing and security into the estimates we provide and be persistent when it comes to the corner-cutting excersises and priotise delivering stable, quality and low-debt solutions rather than delivering a hacked-together mess which is impossible to extend two years down the line, when the backlog finally catches up.