[ibimage==36256==Original==none==self==ibimage_align-center]
By Tori Wieldt
What is Technical Debt? According to developer Nina Zakharenko, it’s the result of a series of bad decisions that force a developer to use more resources to accomplish less. In a talk presented at Pycon Montreal earlier this year titled “Technical Debt: The Code Monster in Your Closet,” she described her experiences with Technical Debt and made suggestions on how to deal with it. And she should know: With more than eight years of development experience, Nina revealed playfully, “I’ve seen things.”
Technical Debt is caused by all developers. It begins with rookie mistakes like not seeing value in unit tests and not being able to say no to adding spurious features. (It’s important to think things through before adding anything to the code base.)
But experienced developers also contribute to Technical Debt. Overly optimistic project estimates can cause a time crunch on projects that leads to cutting corners and skipping steps. When Nina asked session attendees, “How many of you have said, ‘I’ll put it in now and clean it up tomorrow?’” most people in the room sheepishly raised their hands. But when she followed up by asking, “And how many of you really do go in and clean it up?” fewer attendees raised their hands.
In many organizations, the pressure to “just ship is it” is immense. Many developers cut and paste code from places like Stack Exchange without necessarily understanding exactly what the code is doing. And too many developers fall in the trap of believing that more lines of code means more productivity. “Simple is good,” Nina said simply.
Sniffing your code
Technical Debt isn’t just bugs. Nina described “code smells”: issues that don’t rise to the level of a bug because the application still works, but are usually indications of problems in your code, including
- Duplicate code
- Large classes
- Half-implemented features
- No or poor documentation
- Commented out sections
- Large chunks of the code that everyone is afraid to touch
Technical Debt over time
How much attention do you have to pay to Technical Debt? That depends on how long you think your application will last. A couple months? Then you don’t have to worry.
Realistically, however, most code in production lasts years, if not decades. Ironically, early success could be your enemy. Nina recalled that she once worked on a project created by a single developer in “a coffee-fueled 48 hours.” The project was initially successful, but since there were no design plans or unit tests, the Technical Debt grew exponentially.
Over time, it became harder and harder to add features. Every new release broke things. The code was increasingly frustrating to work on. Eventually, the project was deemed too difficult to maintain and was canceled.
Finally, Nina described “the culture of despair” created by Technical Debt. If your code is already a big heap of trash, she said, there’s always the temptation to just add more trash to it. Working on bad code is discouraging.
Fighting Technical Debt
How do you cure Technical Debt? The first step is to clean up your code! But don’t point fingers, Nina warned. Instead, work together as a team to create code standards. Figure it out, write it down, and then stick to it.
Refactoring is perhaps the most important tool you can use. Make your variable names understandable and logical. Use pair programming to make it harder to include something that “you’ll fix tomorrow.”
Insist on code reviews. Make sure that unreviewed code does not go into the master code base!
Another way to reduce Technical Debt is to stay accountable. Use unit and integration tests. Fix broken tests. Use continuous integration. Buy into the programming equivalent of the Boy Scout principle of “Always leave a campground cleaner than you found it.”
Getting management buy-in
All of this takes time, so how do you get management to buy into spending the hours needed to reduce Technical Debt? You can try explaining that better code is less error prone, easier to maintain, and easier to add features to. Remind execs that Technical Debt causes frustrated developers, and frustrated developers are more likely to leave the organization. Replacing them is difficult and expensive.
It comes down to the classic ski rental problem: You are going skiing for an unknown number of days. You can rent the skis for $1 a day or buy them for $10. At some point it’s less expensive to fix ongoing problems (buy the skis) than it is to live with the recurring costs (renting the skis). Show them this graph:
Yes, it can be frustrating to fight Technical Debt. After all, you are trying to clean up months and years of bad practices. But don’t give up. “The results are so worthwhile,” Nina promised.
About the Author
Tori Wieldt is a New Relic Developer Advocate, which means she writes blogs, speaks at New Relic User Groups and events, and seeks to empower and educate New Relic developer users. She has been in the tech world as a sys admin, tech writer, and marketeer. View posts by Tori Wieldt.
