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!
I have been paying student loans my entire adult life. Last month I made my final payment. I now own this Master’s degree free and clear and will be starting out 2019 student debt free! pic.twitter.com/wYL8MWB1iO— Carey Morrison (@pennorrison) January 4, 2019
One doesn't have to Google far to find various approaches to applying the KonMari™ method to code.
- KonMari Your Code; Refactor Your Life
- The life-changing magic of refactoring
- Dealing with technical debt while delivering— a 3 step technique with example
Marie Kondo has done more for containers than docker and kubernetes combined.— Hanny new year! 🥂 (@hannahcancode) January 6, 2019
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:
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?
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.