Like it or not, traditional development approaches can slow you down. Find out how an Agile development pathway can help you pay back technical debt. (And help you reduce the amount of tech debt you accrue in the first place.) Go Agile, and do better!
Waterfall development practices just ain’t what they used to be…
Despite best efforts, those who practice more traditional software development methods (like Waterfall) are more likely to get stuck in project minutia. Teams can get lost in complexity, and (gulp) get burdened by snowballing technical debts.
By nature, software development must be a very careful process, and Waterfall approaches simply allow too much room to derail.
If that sounds like the synopsis of a horror movie you don’t want to see (not even at home and in broad daylight), you need to buckle down and go Agile.
Pay Back Technical Debt with Agile Software Development
You see, an Agile development approach can do a lot for your software development process. And while it may initially require some intense focus to adjust traditional habits into Agile ones, this iterative approach will improve the way you build software.
You know I’m telling the truth about this because no one sells “Agile.” Agile is a behavior, not a commodity; and if you DO Agile, you can free yourself from the old ways of Waterfall and even pay back old (or ancient) technical debts.
Here’s how...
But first, let me tell you a little about why:
Why does a “traditional” development approach lead to more technical debt?
The succinct answer is: bugs
Traditional methods allot inadequate time to manage and fix bugs. This is a dangerous game which, at best, results in clunky software that becomes even clunkier over time.
So, because a Waterfall process leaves more time for bugs to pile atop one another, it can lead to software that looks like a half-baked, super unsavory layer-cake. That’s gross, and that’s quite literally the definition of tech debt.
Technical Debt
Technical debt happens when software developers write poor or buggy code and then don’t fix it. Usually they plan to fix it later (or not), but then one sloppy line of code turns into another; and one bug begets yet another; and soon enough, your software is cumbersome and confusing, it’s hard to read and hard to maintain.
Then, managing future work becomes contingent on tiptoeing around buggy, fickle features, your developers will tire of a crappy code-base, and, eventually, your users will abandon inferior software.
In this technical debt snowball realm, even good coders can get stuck in an illegible code-base and, potentially, your software can reach a point where, realistically, it’s no longer repairable…
So how do you avoid that? How do you structure a development process around writing and maintaining clean, high-performance code?
The answer is: Agile
Agile software development is about a lot of things but, at the end of the day, it can be boiled down to something as simple as technical debt prevention.
In essence, preventing technical debt is what allows Agile software development to be, well... Agile.
You see, Agile is iterative, which means it divides one project into multiple, more manageable segments. Instead of delivering a “finished” product in 6-months, Agile delivers incrementally, and functional software is produced in much smaller chunks of time called sprints (which are usually two weeks long).
This iterative design ensures higher-quality code, more checkpoints against that code, and two other things:
more time to manage bugs (because testing and refactoring are built into each sprint)
-- and --
a greater necessity to eliminate bugs (because working software must be delivered at the close of each sprint (and, of course, one cannot deliver buggy software to expectant stakeholders)
What else?
Agile means ready-to-release software is delivered every two weeks. The key there is “ready-to-release.”
Ready-to-release means clean, beautiful, finished, tested code. And working in sprints ensures clean, beautiful, finished, tested code is pumped-out twice per month (and never on top of something messy or incomplete).
That means that every new piece of software is deployed into a clean, beautiful, high-performance code base.
Now-- do you see any wiggle room for tech debt to grow in an environment like that?
The answer is: no
Hallelujah, right?
Yes. Definitely hallelujah.
But that doesn’t mean an Agile process does all the hard work for you. Instead, it means that if you are true to an Agile process-- if you do the work to change your habits and honor effective programming practices-- you can build better software, and you’ll probably even do so faster and with less stress.
Depending on your situation in the world of software development, this might be a huge shift for your team. But if you can focus your effort on producing small pieces of perfect software, you will never have to suffer through the technical debt snowball realm.
That’s how an Agile process can help you prevent tech debt. But how can you use Agile to pay back technical debt inherited from old code?
The answer to that question is longer, but, in two words it can be summarized as: eliminate it
That sounds like something the Terminator might say, but it’s the truth. Where old tech debt is concerned, you might have to get ruthless.
Addressing Technical Debt
The first step towards addressing any problem is accepting and defining it. Define your tech debt, and work towards correcting it (even if that means eliminating certain features altogether).
The trick here, is that everyone on your team needs to have a unified understanding of what technical is and a mutual understanding that it needs to be repaired. When all team members agree that eliminating tech debt (or at least identifying and managing it) is a priority, the odds of overcoming it are much higher.
This means… You can do it!
Organize your product backlog to include technical debt management, and you will never get in over your head.
As aforementioned, you can build this practice into each and every sprint to ensure your code is always pristine and never sluggish.
Important Things to Note
Also as aforementioned, Agile is a behavior. This means Agile is a verb, so you have to DO it. You can’t compromise or cut corners. If you do, then you are not doing Agile and you’re not going to stay tech debt free.
Another Agile way to stay ahead of technical debt is to add automated testing. This will help you find and fix bugs, and help you catch and prevent them in the future. If you honor a test-driven development approach you can ensure that every feature you deploy is fully ready for production use.
Eliminating Technical Debt in Old Code
This is where the Terminator comes in…
In cases involving loads of old technical debt, assess with your team (and with the help of applicable user metrics):
how utilized are affected features
are affected features necessary to a satisfying user experience and/or an effective ascension path
if so, how long it would take to properly rebuild affected features
is it worthwhile to rebuild affected features
Once you can answer those questions, you can determine whether or not you want to invest in fixing or rebuilding features. If not, cut your losses and eliminate code entirely.
Ruthless, I know. But sometimes a ball-and-chain has got to be ditched. Because sometimes less way more; and having more features might actually be a disservice to your software (and your users) if those features are clunky or unused.
Plus... Imagine how great that could feel? Like spring cleaning for your code base!
Before taking the ax to old features, though, be sure it’s not going to break everything else if you do so. Technical debt can have a domino effect in that, if one feature goes down, it might bring adjacent features down with it.
If you decide to remove a feature that users still value, consider rebuilding it first or providing an adequate alternative feature. Cleaning-up your code base should help you grow, not displace customers. If removing a feature will dramatically affect your usership, make sure you consider every outcome and every option before removing it.
If you determine to eliminate multiple features, remove only one feature at a time. This is a careful way of cleaning-up that will help you avoid surprises and maybe offer insights into other issues in software performance.
Another sneaky way to manage technical debt is to improve your UX.
While that may seem somewhat obvious, it’s an underutilized approach to identifying and eliminating technical debts. In a way, it’s a front door entrance to a backdoor problem and, for that reason, it may actually give you an even clearer view of your code’s performance.
View your software from a user’s perspective, and figure out what it can do better. In this way, you can clean-up your code by looking for clues in your user experience.
Change Your Approach
In conclusion, if you want pay back technical debt and start improving the performance of your software, you have to change the approach with which you build it. Shift your development habits and your team culture toward Agile software development. Agile will help you pay back technical debt and prevent it from slowing you down in the future.
You know how it goes, you have to defeat or be defeated. So if you have identified technical debt in your software, you have to fix it. Go Agile!
Tell us about your experiences in the technical debt snowball realm!