Surprise! It's your lucky day. Your colleagues have dropped off a present: an almost-finished code project, just begging for a last polish. They could finish it themselves, they say, but they've been assigned other tasks. It could be really useful to you, too. It just needs a few more features to make it complete.
Except you know better. This isn't a gift. It's a big ball of mud the other product team needed to get off their books, riddled with bugs and messy code. It will take your team months, maybe even years, to clean it up. To do that, you'll have to ask for funding, raising questions about why you need more money for a product that's supposedly all but complete.
You can see what's coming next. You're a good citizen. You don't want to throw the other team under the bus. All you can do is squeeze in a couple of small changes to get to minimum functionality. The upshot: Disappointment for management. Trouble for you. A mess all around.
Here's how to avoid becoming trapped in a software development Ponzi scheme.
How did we get here?
Why does this happen? You can't just chalk it up to technical debt. The question is why the debt accrues in the first place. In my experience, the answer has to do with bad practices and misguided incentives that make teams behave in nefarious ways. Think of this behavior as a kind of tech-debt Ponzi scheme.
In a traditional Ponzi scheme, a financial manager lures investors with seemingly incredible returns year after year. The secret is, he's not really investing at all, just skimming capital from new investors to pay out the older ones.
Eventually, the fraud is revealed when the bulk of his investors demand their money back at the same time. Since the capital has already been spent down, the manager can't pay the investors, and the scheme collapses, as infamously happened with Bernie Madoff during the 2008 financial crisis.
A developer's Ponzi scheme starts innocently enough, with the annual race for budget. Many organizations believe the best way to incentivize teams to work harder and build better products is to make them compete for funding. The first to the finish line takes the lion's share of money. This is where the great tech debt pileup begins.
The team that usually wins these races is one that's new to agile. Let's call it "Team Madoff." It doesn’t win because it's faster, but because it cuts corners.
It doesn't structure code correctly. It doesn't use automated testing, semantic versioning, or loosely coupled services. It does quality assurance (QA) instead of quality engineering (QE). It might even inflate the value of story points. In sum, it doesn't actually invest. It just pretends to.
This works for a while (or seems to), but over time the cost of maintenance and extensibility catch up with the team. Now Team Madoff is swatting bugs left and right, to no avail.
The team claims to be "done," but in reality it's entering bugs every time it accepts a story. It spends funds slated for new features on fixing existing code. It allocates so much of the sprint to troubleshooting, it has to cut more corners to win the next round of funding.
Team Madoff's big mistake
At this point, Team Madoff has fallen into an almost irrecoverable spiral, constantly paying back the debt it incurred in the last sprint. The team should tell management, but it doesn't. It just writes messier and messier code to keep up, sinking deeper and deeper into its own muck.
Now, up to its elbows in debt, Team Madoff looks for some poor schlep to pass off ownership. That's where you come in. If you can't dodge the project, you'll wind up taking it on, with all the reputational damage that comes with it.
And when you ask for more money to clean up the legacy chaos, your team ends up looking like the bad guys.
The real villain in a Ponzi scheme
The bad actor here isn't Team Madoff. The real villain in a tech-debt Ponzi scheme is agile anti-patterns. An organization that incentivizes product teams by pitting them against each other for budget, and measures them by comparing story points, only encourages this shameful behavior.
Agile anti-patterns are often created by enterprise finance models that favor big-ticket items. Teams are forced to tack features onto huge, all-or-nothing propositions to win budget for smaller projects, and end up competing against other teams. It's similar to how Ponzi scheme operators need to rope in new investors to keep the scheme going.
The scheme unravels
As with the classic Ponzi schemes in financial services, tech-debt schemes unravel when the asset owners stampede for the door. While product teams live out the day-to-day horrors of technical debt, it's the product owners who lose the most.
They're the ones who need to pick up increased operational costs. They're the ones waiting for ROI and not getting it because the dev team is spending all its time hunting bugs instead of building new features. Those mounting operational costs eat away their bottom line.
The scheme should end when management realizes it can't recoup its investment on ops. Unfortunately, it only encourages management to cut expenses. Managers insist on dollars going to code and nothing else.
Since automated testing is perceived as slowing development down, it's often the first on the chopping block. Some companies (even ones practicing agile) even believe automated testing is more expensive than manual testing. They'd rather throw offshore bodies at the problem as a cheaper alternative.
Eventually they hit a breaking point. No matter how many bodies they throw at the problem, regression testing keeps getting longer. Management calls a rewrite, but now it's too late to turn mud into pearls.
Adding a new feature takes five times longer than it would in a clean codebase, and they rack up expenses with every change you make to the legacy codebase.
Wading out of debt
What can you do if you find yourself in this situation? As any good financial planner will tell you, there's no silver bullet for getting out of debt. You have to pay down tech debt over time.
Start by committing to automated testing. Introduce pinning tests. Set a goal of "everything net new." Create a slice in the application where you can start to move things long-term toward better patterns.
Your goal is to keep the same surface area while changing the way it functions internally. Pinning regression tests are brittle, but they're overarching.
You can always rerun the regression tests to see if you've broken anything. See the chapter on "seam models" in Michael Feathers' book Working Effectively with Legacy Code, for more on how to write tests for poorly suited existing code.
Dodging a Ponzi scheme before it snares you
The best way to avoid tech-debt Ponzi schemes is to keep them from getting off the ground in the first place. You need to prevent teams from moving fast at the expense of quality, and that requires an organization-wide commitment to UX, QE and DevOps.
A focus on UX ensures that you're building the right product. All too often, products are cobbled together to meet the developers' needs, not the end users'. Each iteration is little more than a vehicle to secure the next round of funding.
Needless to say, that's the wrong way to go about it. The right way is a UX-centered approach based on firsthand end-user research and feedback from all levels and personas.
Automated testing via quality engineering verifies everything along the way, so you can move fast without regressing. It's likely you'll find bugs you didn't even know were there while trying to add in new features. In the process of fixing old bugs, you're still improving the product and adding automated tests for the net-new.
Finally, DevOps integrates automated testing and helps you deploy code seamlessly from development to testing, staging, and production. Team Madoff does live testing in a production environment. Don't be like Team Madoff.
Healthy product teams: The low-risk, high-reward investment
Product teams with these three elements in place can run at the same pace forever. Those without them tend to fall into technical debt. Eight-week sprints become quarterly sprints as their regression testing blows into the next cycle.
Eventually the team moves to yearly releases. The yearly release incites the huge fight to get features in. The cycle repeats.
Just as a good financial planner will tell you it's better to pursue strong, consistent returns than chase big windfalls, funding steady-state product teams—ones with established UX, quality engineering, and DevOps integrations—should be a no-brainer.
Likewise, management needs to understand that pitting product teams against each other doesn't bring out the best in them. It makes them sneaky and dishonest, and creates an environment where mini-Madoffs thrive.
A competitive spirit is all well and good, but not at the expense of a healthy product portfolio. It's as true about software as it is about finance.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
