What happens to code when you don’t refactor? Anyone with any experience knows the answer. It gets messy. It becomes hard to change and the rate at which you can add features slows to a crawl.
In the Agile Development community, we use the term “technical debt” to refer to this problem. When you don’t keep your code clean, you incur debt, and as in other areas of life debt reduces your options – it can become crippling over time.
More and more, however, I wonder whether there could be a different way of looking at the messy code problem, a way that takes people's behavior into account.
The other day, I saw a news report that offered some advice for people who were cutting back on their spending. The advice was to throw away your credit cards and use cash. It turns out that people spend less when they are handing cash over to a cashier.
When you think about it, it makes sense. There is something fundamentally different about parting with something valuable that you own. I have no doubt that credit card companies know this also. People feel much freer spending money that, technically, isn’t theirs. And, to the degree that the transaction doesn’t feel “lossy”, people will spend. If recent history tells us anything, it tells us that in general people just don’t seem to mind accumulating debt.
The idea that I have in mind is to flip technical debt around. We need to see clean flexible code as an asset and count it as an asset. When a non-technical person wants something faster, we need to be able to talk about how much of their asset they would be losing if they want a rush job. They also need to know how much it would cost to restore the asset, and it’s almost always far more than the original development cost.
The devil, of course, is in the details, but I do believe that we’re better off aligning with human nature. People like to accumulate assets and they hate losing them. We need to recognize the value of clean, supple code and make sure people understand the business impact of losing it.