Technical Debt is a developmental plague. Traditionally, phases of development guide the Software Development Life Cycle; Feature development, alpha, beta, and finally the elusive golden master.
Ideally, every release has new features being built and previous issues being solved. Obviously, it’s never this simple. Our development cycle would reach alpha once all your functional features are implemented and are ready for testing. Then, the process takes us through an intense round of audience feedback to find out more breakpoints. This stage is beta. And like every software warrior knows, the more bugs you kill, the more bugs appear from seemingly nowhere. After this constant battle, our release finally reaches the sacred golden master milestone when there are rarely any open bugs. But the software warrior knows that he has just fixed some bigger known issues and delaying the rest to the next release.
What is Technical Debt?
Constantly procrastinating on bugs that have easy fixes is a dangerous way to make software. As the bug count grows, tackling it becomes increasingly daunting–resulting in a vicious death spiral of technical debt. To make matters worse, you can derail schedules because coding around the bugs slows down development. Meanwhile, customers are experiencing death by a thousand cuts caused by un-fixed defects. And indeed, some of them will leave you.
There is a better way.
End-to-End Testing on real iOS, Android Devices & Browsers
Reducing technical debt through agile
Agile adds quality into the traditional phase development approach. Resulting in the team’s ability to maintain a consistent level of quality release after release. If a particular feature isn’t up to mark, it doesn’t ship. Here’s how we do it: defining or redefining, the definition of “done.”
Traditionally, “done” means good enough for QA to begin. This is problematic. Bugs tend to creep in early and keep coming. This has the development team ending up with absolute bug-riddled junk. We do it differently with Agile. By changing the definition we change the workflow, therefore – developers do not work on the next feature till their current item has reached the consumer. Ans to get things working faster, we use techniques like feature branching workflows, automated testing, and CI/CD throughout the development cycle.
The prevention of what we refer to as “technical debt” is what helps us be Agile and much much faster and more efficient.
Always keep your master branch of the codebase ready for shipping. Keep this as your number one priority. Then you could have new features on a task branch that contains code for the feature itself + automated tests. After completing the feature and passing the automated tests you could merge it with the master code. Technical debt stays under control, and you maintain a high bar on quality assurance.
Using Agile, this change in focus from schedules and towards high-quality, demonstratable software has been a massive cultural change for a lot of organizations. Now, the product owner is challenged to create the most valuable work first – without compromising on quality, now that the scope of the release has been reduced.
Managing your team’s technical debt
If you have been working with legacy code, I’m sure you must have encountered considerable technical debt. The following topics will help you tame existing debt, and enable your team to focus on the fun stuff like new feature development.
Define it
There is often disagreement between product managers and developers as to what actually constitutes technical debt. Here’s your line in the sand – Technical debt is the difference between your promise and the delivery.
This includes all and any technical shortcuts made to meet delivery deadlines!
Usually, developers tend to categorize architectural work as technical debt. This is a variable from project to project, and/or even shipment to shipment. On the flipside, product management is almost always a rush to build more features rather than fixing bugs or slow performance.
To avoid these situations it’s better that everyone is on the same page when it comes to technical debt, desired architectural changes in the code base, and new features. Clear and constant communication is key – between the developers and the product managers when it comes to prioritizing the backlog and evolving the codebase.
PRO TIP:
Work on technical debt in sprint planning just like normal feature work. Don’t hide it in a separate backlog or issue tracker.
Beware of testing sprints and tasks
We’ve changed the definition of ‘done’. Don’t add a separate testing task to the original user story. You’ll only invite more technical debt by the virtue of it being easy to defer them. Keeping a resolute definition of done in our program and making sure that it includes complete automated testing. You know that a buggy codebase and manual testing will bring your team’s agility down.
Automate bugs away
Take a while to add an automated test when you discover a bug in the software. And once it’s fixed, run the test to make sure that it does pass. This right here, is the core of test-driven development, a long-standing SOP for keeping quality high in an agile environment.
Where to start?
Changing the definition of debt is easier said than done. And so is changing the team’s values on managing technical debt. Change is tough.
But development exists to serve the business. And this will help you get to market sooner. Let’s do a quick recap –
- Educate the product owner on the true cost of technical debt. Ensure story point values are accurate for future stories that require resolution of existing technical debt.
- Modularize your architecture, and take a firm stance on technical debt in new components or libraries in the application. As the team and business see the agility in these new components, they will naturally want to extend those practices to other parts of the code.
- Write automated tests! Nothing prevents bugs better than automated tests and continuous integration. Write a new test when a bug is found to reproduce it. And then, fix the issue. If that bug ever resurfaces, the automated test will catch it before customers do.
Remember, technical debt is a reality for all software teams. Nobody avoids it entirely–the main thing is to keep it from spiraling out of control.
