Technical Debt
Have you ever shipped a system completely free of technical debt? An application where no corners were cut and no compromises were made in service of deadline or budget? Small personal projects aside, over a 20+ year career, I have never seen such an application in a professional setting.
Author’s Note: This post is an excerpt from my weekly Dev Mastery newsletter. It was originally sent to Dev Mastery subscribers on December 8, 2016.
Check out this article from Tech Crunch about strategically planning your technical debt so that it can be managed and leveraged for maximum benefit.
The article makes some good points, but the author is clearly from a software product company background. There’s no question that it’s hard to convince a product manager to invest in a specific project dedicated to resolving technical debt, especially when that investment won’t result in any new features that the average customer might immediately notice. But at least at a software company there is some vague understanding of the business risk of technical debt. This understanding is much harder to find at agencies, consultancies, and in large enterprises.
If you’re not in a software company, it’s almost impossible to get anyone to approve some specific future project aimed specifically at eliminating technical debt. You have to pad your estimates for fixes or new features so that you can go back and clean a bit of your mess. And you have to be extremely careful about the kind of messes you make to begin with.
Speaking of cleaning messes, refactoring is an important skill for any developer. I’ve written about my approach to this before in…
Martin Fowler also maintains a good listing of common refactoring techniques that I often use as a reference…
The five I use the most are:
The post you just read was originally sent to Dev Mastery newsletter subscribers on December 8, 2016. I send out stuff like this every week. Sign up below to get in on the action.
