I've had an interesting talk with one of my friends, who's not really into those magical "useless" crazy stuff we're doing just to get metrics about the "quality" of our code.
He explained, that most of the programmers like to think of code as slaves. It needs to be tortured to do exactly what they want it to do. Sure, this is a working approach, but takes a huge amount of energy to regulate the codebase, and prevent it from rebelling.
Imagine you're working on a project almost a year or so and everything seems to be going well until some minor changes break the consistence, and bugs start evolving from nowhere. It's like cancer. You fix one cell, two others seem to come. Most of the times the cure is either expensive, or impossible. Shotgun surgery can help, but you'll never want to touch your code again.
Familiar?
I'm sure that most of the coders in the (at least the www) world are struggling in a huge pile of
Technical Dept - not even knowing what it is.
TechnicalDebt
You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
The tricky thing about technical debt, of course, is that unlike money it's impossible to measure effectively. The interest payments hurt a team's productivity, but since we CannotMeasureProductivity, we can't really see the true effect of our technical debt.
One thing that is easily missed is that you only make money on your loan by delivering. Following the DesignStaminaHypothesis, you need to deliver before you reach the design payoff line to give you any chance of making a gain on your debt. Even below the line you have to trade-off the value you get from early delivery against the interest payments and principal pay-down that you'll incur.
Technical Debt comes in various forms, some of which can be good and some bad - I use the TechnicalDebtQuadrant to describe them.
(As far as I can tell, Ward first introduced this concept in an experience report for OOPSLA 1992. It has also been discussed on the wiki.)
Martin Fowler @ http://martinfowler.com/bliki/TechnicalDebt.html
The same scenario could be applied to all levels of life. Company management, Governance, etc. People want other peoples working like slaves, without questions, without thoughts, and maximum effectiveness. You wouldn't go working for a company that will treat you like a slave, give you minimal money. But what is so magnetic about working for (let's say) Google?
Would you like to work here?
Of course you do. There's no sane person in the world who wouldn't like to spend the day in such environment for such salary...
But how does this apply to code quality?
Code is just like a simple employee in any company. You need to care for your workers, provide them everything you can to make them happy, just as mentally healthy. "But the code doesn't have needs!" - you say, but you're wrong. Of course it can't tell it's needs on it's own, but it has a language of metrics that can come handy. Measure coding standard violations, testability, writing unit-, integration-, end-to-end tests, collecting it's coverage data will get you a full report on the health of your code... trust me, it's worth it. The more healthy your software is, the easier will it be to apply changes to it. (= make the same amount of money, with less effort) Think about it.
