hogshead@Tumblr

Technical Debt
We know that all successful software gets changed. So if we think we’re working on code that will be successful, we know we need to keep it easy to change. Anything that makes code difficult to change is technical debt. We know that technical debt drives the total cost of software ownership relentlessly higher, and that eventually we will have to pay it off or the system will go bankrupt. And yet . .

1. We tolerate obscure code, instead of making sure that all code reveals its intentions to the next person who comes along. Developers, especially apprentices, should be taught how to write “clean code”: code that is simple and direct, with straightforward logic. Senior technical people need to ensure that messy code, even if it passes the tests, is never admitted into the code base.
2. Far too often we don’t take the time for refactoring: consolidating changes into existing code. Refactoring is essential for iterative development. Adding new features to existing code creates complexity, ambiguity, and duplication; refactoring pays down the debt.
3. We run regression tests on our systems before deployment. At first they are quick, but with each addition of code, regression tests take longer and longer and longer. As the regression deficit grows, we increase the interval between releases. The only way to break this unending cycle of increasing release overhead is to decrease the regression deficit. If we had started with automated test harnesses back when the code base was small and added to and maintained them, we could make changes to our code almost as quickly today as when the code base was new.
4. We know that dependencies are one of the biggest generators of technical debt, and yet we are ambivalent about replacing obsolete systems with massive dependencies. We must develop, and migrate to, architectures that minimize dependencies. We have known for a long time how to do this: Focus on information hiding and separation of concerns.
5. We branch code for many reasons: to isolate new development, to focus on an individual application, to create parallel feature sets. And we know that the longer two branches of code are apart, the harder they will be to merge. And yet we wait for days to build our code, and worse, we delay system testing until the end of development. We don’t realize that this isn’t necessary anymore; the big bang is obsolete.

We need to expose technical debt for what it is: a costly burden to be avoided lest it lead us into bankruptcy. Chapter 2 will look at software development through a technical frame and discuss solid techniques for avoiding technical debt.