Well crap! Several weeks ago I was laughing with my co-workers about people who have nothing better to do then argue about the what ‘tech debt’ is. So now I’m posting about what ‘tech debt’ is.
So, I’m an asshole.
Uncle Bob had tweet about messes. This tweet.
I and others debated with him on twitter.
Things quieted down. Then DocOnDev posted this.
I was going to leave a long and rambling comment on Doc’s post. When I finished, I realized that it was long enough and rambling enough to be a blog post. So here we are.
Since arguing with Uncle Bob over that tweet, I’ve had time to think about this, so I’m going to indulge in some rambling commentary:
Writing software is a human endeavour. There will be messes. We may find them distasteful, but they are normal. And you won’t eliminate them by fiat.
If you have more then one committer on a project, you are at risk for accidental code duplication; new developers to the team will make naive mistakes; someone is going to try to sneak that multi-purpose Util class in there somewhere (arrrgghh); and a lot of code just isn’t going to express its intent.
When we go to refactor this code, will we treat it differently because its “distasteful”? Nope. We will test, and we will refactor, until the code is clean, just like any other debt. We need to account for these messes when we are considering how much of our budget goes towards paying back debt.
That being said, if you’re intentionally taking on debt by leaving your code a mess, and excusing it by saying “I’m delivering value faster”, then you’re a fool. How many opportunities will your project miss out on because developers will be cleaning up your mess? After all, this is debt. If you don’t pay for now, you’ll pay for it later, with interest.
Tech Debt isn’t supposed to be about taking a crap in your code base and calling it value. I think that may be what Doc and Uncle Bob are getting at.e