A Technical Debt is probably every software team’s biggest nightmare. To the uninitiated, it is a programming concept that refers to the extra development work on hand when the code becomes too hard to change.

Simply put, as you begin with a single change in a complex code, other coordinated changes crop up simultaneously in other parts of the code or documentation, almost like a chain reaction. The other changes are considered Debt that must be paid at some point in the future. Sounds like a bad credit card story, isn’t it? Although contrary to how it sounds, technical debt is not necessarily a bad thing, and sometimes it is just what a team needs to move projects forward.

A technical debt can crop up at several points of your development journey in the form of a scope creep, an under-estimated size of tasks, unaccounted dependencies, high priority tasks taking over planned tasks or even staff dependencies like team members falling sick or going on leave. It gets even harder when a team is dealing with dynamic requirements.

Countering Technical Debt
The industry is yet to figure out a mantra to keep up with fast development without facing serious setbacks due to technical debt. But that doesn’t mean there’s no way out. Here’s a checklist that helps us at VenturePact in dealing with technical debt as a team.

#1 Agree on what is technical debt- Developers and project managers each tend to have their perspective on what technical debt is. While the technical team might feel tempted to characterize design dependencies as technical debt, the project managers often prioritize building new features over fixing bugs. It is common for one party to be jaded by other’s opinion. This difference of thoughts can incur additional development work.

Everyone on the team needs to understand that each extra effort made before completing a task counts as technical debt. For instance, it is the extra hours that goes into changing a code that’s been built poorly just to release a functionality quickly. If the debt remains unpaid, it will keep accumulating, making it impossible to implement changes at a later stage when the system is too complex. Unaddressed technical debt increases software entropy, which means the software will become difficult and costly to maintain over time.

#2 Measure and Track Technical Debt – You can use tools like codeclimate.com to keep the code updated in the right direction. Or, if you are working with a third party, you can use code governance tools like VenturePact.com to run static code analysis that tells you what’s wrong with your code in real time. Once identified, it is important to document the debt instances correctly.

You can also maintain a shame file. This is an effective way of tracking technical debt introduced by architect designer and developer Harry Roberts. A shame file can serve as a repository for known compromises refashioned as a task list for debts that need to be repaid. Such documentation could be performed using simple Excel sheets or with the use of sophisticated tools such as Teamscale.

#3 Build Sustainably – Build your product with long-term improvement in mind. Aim for sustainable development, which is about efficiency and balancing the needs of the short and long term. Make sure that the software you build has the highest possible value for customers, while incurring a minimum possible cost of change. The idea is to create the smallest solution in a minimum period while capturing customer value. This will enable you to respond quickly to future changes.

#4 Automate Your Tests – If you don’t perform automation testing for your code, it means either you are testing it manually, or you are not testing it at all. Either way, chances of accumulating technical debt are high. Manual testing doesn’t scale well with system complexity.

Automated tests, on the other hand, don’t only fix bugs faster but also help build a sustainable foundation for systematic code reuse. Thus, whenever you discover a bug in your software, take out time to add an automated test that demonstrates it. And even after fixing the bug, rerun the test just to be sure. Often known as test-driven development, this methodology has been helping developers for years in maintaining code quality and clearing technical debt.

#5 Refactor Aggressively – By refactoring we mean changing the way a code is being written, without affecting its functionality; or changing the code structure and yet, keeping its behavior intact.

Here are some parameters to know when to refactor your code-

• If you are adding a hard-to-implement functionality,
• If you are changing a code the second time, you’ll probably change it third, fourth or fifth time as well.

However, refactoring can be a herculean task if you don’t have unit tests in place. Make sure you write tests before refactoring.

#6 Pay Off a Little Debt in Each Iteration – Just like you need EMIs to pay off a big loan, you need ERIs (equated release installments) to pay technical debt. All you need to do is dedicate a small portion of effort in every iteration to refactoring and focus on repaying entities first. Entities here refer to a class, file, or component in your software product.

A technical debt is most impacted by debt instances from other dimensions like the design. It is possible that a couple of changes in the design can make a code testable and reduce technical debt to some extent. Hence, instead of trying to repay completely in one dimension, attempt to repay debt associated with an entity. This process is often called horizontal debt payment.

#7 Have an Engineering Effectiveness Team – The Engineering Effectiveness Team at Twitter believes that a development process can be made more efficient if the right number of people are taken away from actually working on the product for supporting those developing the product. Peter Seibel, the tech lead of this team, feels this effort can help Twitter deal with technical debt to a great extent. “Technical debt compounds over time. A little bit of debt when there are ten engineers kills you when you get to 1000 engineers,” he said in an interview. “My dream is having a team of senior engineers,” he says, “who can drop in on some code, make it better, and then get out of town.”

#8 Reward Team Members to Maintain Quality – Reward and recognition are key motivators for everyone in the organization, including your development team. Remunerating people in your team could prove to be an innovative way of dealing with technical debt. Measuring the number of bug fixes as a yardstick of performance, and rewarding your devs for it, will not only motivate your team to fix more bugs but also develop high quality working code.

Code quality is undeniably a strategic arsenal in the battle against high technical debt. But how you reward your dev team is equally important. If you think what motivates the rest of your employees will also motivate your geeks, you are WRONG! Daniel Pink reveals that developers’ idea of reward focuses on three key ideas – autonomy, mastery, and purpose. Take the case of Atlassian for instance. They know how passion drives geeks, and thus organizes Fedex challenge where everyone in the company can work on what they love, and present it to the company within 24 hours. Now that’s how you drive passion and keep your team motivated!

Have you dealt with technical debt during a project at your organization? What measures did you take to deal with it? Do let us know in the comments section below.