Escaping Technical Debt
October 30, 2014 Leave a comment
On October 6th we had Michael Feathers (@mfeathers) author of Working Effectively With Legacy Code visit our facility. The visit was two achieve two objectives. The first was to give tech talks to our engineers about legacy code. The second was to train selected key individuals in the organization. Specifically, techniques and skills on how to deal with legacy code.
Mr. Feathers graciously agreed to give a recorded community talk about Escaping Technical Debt.
- Tech debt
Technical debt is a metaphor for the amount of resistance in a system to change. The larger the debt the higher the resistance. When change is introduced, the time spent looking for where to make a change is one example of tech debt. Another is when the system breaks in unexpected ways.
- It takes a community to mitigate technical debt
Tech debt affects everybody, from engineers, to product owners to the CEO. Mitigating tech debt requires everyone’s support and involvement. As Engineers, we are responsible for how to mitigate technical debt. The product owners should have input on tech debt mitigation effort. The benefits of tech debt cleanup should be visible to everyone. Don’t surprise your peers or management by the sudden change in productivity. They will bring ideas to you to help pay down the debt in more enabling ways for the future… Involve them!
- Don’t pay the dead
Code that doesn’t change, even if it is in production, doesn’t collect debt. Dead debt is any part of the system that doesn’t change including bugs and poor design. Many times engineers get wrapped up cleaning code that isn’t changing. Resist the urge to refactor unchanging parts of the system. If it isn’t changing it, it isn’t technical debt, it is dead debt, walk away.
- Size your debt
Target the most complex changing code ordered by frequency of change. Build a dashboard to show the amount of changing code by frequency. These are the most expensive tech debt hot spots. This should be the focus of the tech debt cleanup effort.
- Seal the leak
Technical debt should be paid down immediately. Simple code is easy to make more complex, and easy to make simple. However, as the code becomes more complex, the balance tips in the favor of adding complexity than removing it. No matter how complex the code is, it is always going to be easier to add complexity than remove it. Inexperienced engineers, fail to see the initial complexity that is added to the system. In turn, they follow the path of least resistance making the code more complex.
To seal the leak, first identify the most complex and frequently changing code. Second, give explicit ownership for that code to the most seasoned engineers. Third, let the seasoned engineers publish the eventual design objectives. And finally, owners should review all changes to the code they own.
- Slow down to go fast
Clean code takes time and disciplined effort. Adequate time is needed to name classes, methods and variables. Poorly named methods and classes will create confusion. Confusion will lead to mixing roles and responsibilities.
Finally, low tech debt will yield high dividends with compound interest…
“Don’t do half assed, just do half”