Part 2 - Tech Debt is a Messy Closet

You may want to start with read part 1 if you haven't read it already.

Once you've identified some tech debt, chances are there is more that you've yet to find. But do not despair! Debt is useful, and making that "final" payment feels really good!

One doesn't have to Google far to find various approaches to applying the KonMari™ method to code.

Having a strategy is a good idea. Having an analog in the real world is... well ask OO vs. functional advocates, but maybe we can utilize some additional software development oriented thinking to come up with steps to tackle technical debt. When it comes to tech debt, there is bound to be some refactoring.

In Refactoring: Improving the Design of Existing Code, the authors write:

Whenever I do refactoring, the first step is always the same. I need to build a solid set of tests for that section of code. The tests are essential because even though I follow refactorings structured to avoid most of the opportunities for introducing bugs, I’m still human and still make mistakes.

That sounds good to me. Hopefully you can build tests for the code you have, but what do you do if the code you have is not testable? Is that a need for refactoring in an of itself? If so, where do you begin?