You Might Have Technical Debt If…
A fellow Agile Coach and consultant recently asked for some non-technical key indicators of technical debt. From my not-so-geeky-girl experience, I have learned some ways to sniff out technical debt, without having to know the code or environment. Before we go over my top ten list, I’d like to explain technical debt in a real-life/not-so-technical scenario.
In software development, technical debt occurs when developers add code to existing, outdated code, rather than taking the time, and incurring the costs of doing it the optimal way.
This situation is also experienced in our day-to-day lives. I identified the following non-technical example, which I’ve so creatively labeled; Non-Technical-Debt.
Example of Non-Technical Debt
The plumbing in my home has leaked in two different places over the past 6 months. The most recent incident led to significant damage, which left me needing to replace my outdated sink and vanity with a newer, more appealing unit, fixtures and features.
When my home was built, they installed polybutalene piping. While this was popular at the time, people quickly learned that the joints were unreliable and frequently burst and leaked. This piping is old, worn and continually needing to be patched. Newer piping materials have proven to be more efficient and are the current standard.
I have been informed by several people that I need to repipe my house to avoid future leaks that could be quite damaging.
So, I’m left with a decision to make; do I replace the sink and vanity, connecting it to the old, unreliable piping? Or do I start from scratch and repipe/rebuild the entire system?
When I had my first leak, I chose to patch it and leave the pipes as they were. That was the choice I made at the time. Now, 2 leaks later, I have learned the old system is unreliable enough to merit a rebuild. This is quite similar to decisions that developers make when they implement new features on older systems.
Due to the high risks of keeping the old plumbing in my house, I have chosen to do away with the Non-Technical Debt, and incur the cost of rebuilding the system.
Replacing the sink and vanity while leaving the old piping is like adding new features on top of existing, outdated code written within a web application that was not initially designed to integrate with the new code or feature.
When non-technical managers, Scrum Masters and Agile Coaches work with technical teams, there are some key indications of technical debt that can be helpful in identifying risks and introducing discussions about implementing change to the system. The list below is a culmination of ideas from myself and my peers. I welcome your additions to this list … please share your comments below.
You might have Technical Debt if …
- If team members cringe, gasp or crawl under the table at the mere suggestion of changing existing software, you might have technical debt.
- If your team can’t task out a User Story because “… well, see, the guy who wrote that code is no longer with the company,”… you might have technical debt.
- If your team consistently writes the infamous “Research Story” … or 4, which usually drag on over several iterations… you might have technical debt.
- When the team writes tasks to add layers of band-aid code over existing software, rather than writing a solution that works with the existing code … you might have technical debt.
- When your team members band together in a coup against anyone advocating for the change and become hyper-focused on presenting arguments about why not to add the feature, rather than focusing on solutions … … you might have technical debt.
- If your team is talking about, “Cobol, Pascal, Basic, Fortran, QBasic Prolog or Logo” … you’ve most certainly got technical debt.
- If your team has a refactoring, architectural, UX or other comment that is carried across multiple retrospectives ” … you might have technical debt.
- If your team wants to make a change but continually “kicks the can down the road,” … you might have technical debt.
- If your team continually adds stories to the backlog to improve efficiency in the code and/or the database yet does not make the time to address them; you might have technical debt.
- When you hear any of the following comments, you might have technical debt.
a. “If we add that feature, it will break the existing software.”
b. “We’ve changed all 10 places where that logic is coded.”
c. –“We can just copy that code and make a few changes.”
d. –“If we target automate tests behind the UI, we won’t be testing the business logic that is in the UI layer.”
e. –“No, we really did mean 10 weeks rather that 10 days to make that change.”
f. –“Those unit tests kept failing so we just turned them off.”