Real Monster in Closet

What is Technical Debt? According to developer Nina Zakharenko’s session at PyCon 2015 Montreal 2015 last week, it’s the result of a series of bad decisions that force a developer to use more resources to accomplish less. In her session 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.