When my instructor introduced technical debt, he described it as poor design choices that delay the productivity of a development team. When I was learning about how unclean code can slow down the software development process, I asked myself, “Is unclean code technical debt?” To answer the question, I am going to explore and compare the meanings and consequences of unclean code and technical debt. I will be using chapter 1 of Clean Code, written by Robert C. Martin to support the discussion. Chapter 1 explores the meaning of clean code and its value.
Unclean code is code that cannot be read and enhanced by a developer other than the original developer. Some qualities of unclean code include uninformative names, redundant comments, and multi-purpose functions. Some reasons for unclean code may include making a deadline and having inadequate skills. Unclean code is consequential because it slows down the development process. When code becomes unclean, it becomes difficult to read. When it is difficult to read, it becomes to develop. Martin reinforces the value of clean code by talking about how unclean code killed a company in the 80s: “As they added more and more features, the code got worse and worse until they simply could not manage it any longer. It was bad code that brought the company down.” In other words, bad code tempts bad code and as bad code piles up, the application eventually becomes unusable, unmaintainable, and not worth fixing. Unclean code hampers the capacity of an application to be developed.
Technical debt is the time a developer needs to use to refactor the code of a piece of functionality from a previous release because the functionality was implemented hurriedly. In software development, developers may deliver an application faster by using a convenient course of action to implement a piece of functionality. When they tell themselves they are going to refactor the code and add even more functionalities in the next release, they are putting themselves in technical debt. The debt becomes consequential when it is never paid. If developers do not pay the debt by refactoring the code, it may be difficult to understand. The lack of understanding may tempt developers to pile on the mess with unclean code and unintuitive implementations. As the mess grows, the application may become unusable, unmaintainable, and not worth fixing. Technical debt hampers the capacity of an application to be developed.
While unclean code functions like technical debt, I do not think unclean code is technical debt. Unclean code describes code, whereas technical debt describes the extra time a developer needs to use to refactor code. I think the two concepts have a cause-and-effect relationship, where unclean code is the cause and technical debt is the effect. The loss of productive time from unclean code may sway teams to take shortcuts. Understanding unclean code as a cause of technical debt will encourage me to become more aware of the way I write my code.
Martin, Robert Cecil. “Chapter 1: Clean Code.” Clean Code, Apogeo, Milano, 2018, pp. 33–46.
From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.