Beware of Technical Debt and Cruft

If you work on a legacy application, you probably have a code base that is not clean, with all kinds of supporting tests. Let me address what you have and how you might fix it.

We hear a lot about technical debt. I have consciously made the decision to meet a trade show deadline or to meet a demo date for a Very Important Customer. We scripted the demonstrations of those products and told the people running the demos not to stray off the very straight and narrow path.

We didn’t add in all the alternative paths. We didn’t do input-checking for bad input. We didn’t work on performance. We did the bare minimum and it wasn’t pretty. We made the deadlines. We had code for a specific, limited application. We didn’t have enough time to do “all” of it and we were willing to trade off time to make something we could show. That’s a conscious decision to take on technical debt.

Here’s an alternative scenario: You realize after you wrote the code that there is a better way to make that code work. That’s not technical debt. That’s learning. And if you need to address performance or reliability in that code later, that’s a good time to change how the code works.

However, too much of the code I see is a mess. The developer(s) didn’t think about how to structure it. The developers didn’t test it, or didn’t test it well. The testers never got a real chance to test it, or the tests are insufficient for the code. That’s taking a shortcut and it’s not technical debt. That’s a mess—cruft.

One way to help the team avoid technical debt is to create automated tests for release criteria, as described in ​Develop the Release Criteria​. Sometimes thinking about ATDD and BDD tests and automating them (as much as reasonable) can help the team see how to write good code and keep it clean.