A case for the unsexy yet important act of cleaning up code

We asked Chatham Financial developer Mark Schell to give us a peek at a side project he’s working on for our column, Code Annotated. Got some code to share? Email editor Juliana Reyes at juliana@technical.ly. 

---

The purpose of this software is to find unused code in a large code base.

One common challenge I have observed throughout my career is a company’s struggle to keep a code base clean and organized as best defined by Bob Martin’s book Clean Code. Organizations are super focused on delivering new functionality to their users. Equally important is their ability to maintain a certain level of quality, structure and readability in their code base. Maintaining the code quality requires great discipline by the whole team through practices such as refactoring. Without regular attention, a code baseline will slowly move way from a “clean” state and will become more difficult to add functionality. This is similar to the concept of compounding interest in finance. Once this hole of technical debt is deemed too deep, organizations often declare code bankruptcy and rewrite the solution, which can have its own set of issues.
One part of keeping a code baseline clean is the removal of used code and functionality. There are a number of tools on the market that are designed to help organizations solve code quality issues. I have been unable to find one that supports the flexibility necessary to handle micro-service solutions or implementation specific needs. To fill this need, I started the Software Thresher open source project. It is designed to allow each user to configure a series of tasks that support the finding of unused items in their code base. Once configured per the organization’s needs, this can be used as a regular check allowing developers to refocus on delivering new content. Many organizations would be very surprised to see the percentage of code that is no longer used, slowing down future development.

Unused code is very similar to the old clothes in our closets.

Often clean up tasks such as deleting unused code is not prioritized and/or viewed as important work. It is not the glamorous work of using the latest technologies to create a user interface or creating a new algorithm to perform machine learning. Looking at this work from a cost accounting perspective, any effort to clean up the code can be viewed as an expense that is not delivering any new value to the user. However, without some level of clean up the code will get to a point that it will no longer be maintainable, requiring higher longterm costs. Overcoming these perceptions is accomplished through organization education and by showing the potential of the practice via small team results. This transformation through education requires patience.

One of my coworkers came up with a great analogy for unused code. The unused code is very similar to the old clothes in our closets. One day we hope to wear them again and when we try to wear them we find out that they are out of style. All that time crowding our closet and making our decision on what to wear harder every day. In the case of the unused code, it is no longer usable because our infrastructure, technologies or system knowledge has just matured making the code useless. All that time slowing us down from refactoring.
There is nothing that makes the attached code snippets any more special than the rest of the project. The whole project has been developed via Test Driven Development (TDD) with the intent of keeping the code (including unit tests) readable. I would love to hear your comments related to the readability to help evolve my understanding of “clean code.”