My thoughts on technical debt take 2

I did a bad job last week conveying my thoughts on technical deb. A friend that knows me well enough to have an idea of my opinion on the subject let me know that the post didn't sound like me. So, I'll take a minute to try and review what i was saying.

Technical debt as it was originally defined, can be a useful metaphor. My very limited knowledge of how Ward Cunningham originally presented it was that it was not a deep dissertation on the subject but just a little statement that started with "Shipping first time code is like going into debt." The idea being, all the little shortcuts you take to get first time code shipped are like debt, and in order to support and maintain that code going forward you will eventually need to pay that debt back; the sooner the better. If you don't pay that back, the codebase will become unmanageable and the cost of change going forward will keep going up.

Ok, fair enough. A little metaphor to help us be conscious of the cost associated with shortcuts and decisions we make early on in order to ship code faster. And a very good metaphor at that. To be fair though, the opposite end of the spectrum is filled with cute little metaphors and acronyms too; premature optimization, YAGNI (you aren't gonna need it), analysis paralyses, etc.

These metaphors can help us make decisions around things we do and don't do during the process of building and shiping working software. But, to complicate matters, on any given project you will have varying levels of developer experience and skills, and the answer to these questions won't always be the same. I'd probably go out on the limb to say even if you take a room full of developers with basically the same rating of skills they would make varying decisions along these same metaphor points.

Interestingly enough, in my previous post, I really wasn't talking about any of that. I was talking about something I'm calling "Technical Debt brouhaha". Which is more about the manifestation of the technical debt metaphor into something toxic.

When a term like Technical Debt becomes more then a metaphor used to help make decisions, and instead is used by developers of a codebase on a daily basis it can become toxic. When it becomes toxic, developers start using technical debt to mean:
This code sucks.
This isn't how I would have done it.
This code is too procedural.
This code is too object oriented.
Why are you using this gem, plugin, etc; thats a liability.
Why did you write that yourself instead of using this gem, plugin, etc.

Do you see where I'm going? There is a huge difference between using a metaphor to help make decisions, and instead just complaining about stuff. Often, once this toxicity starts it spreads like cancer, and soon every developer in a shop hates being there on a daily basis.

Sure we all have to let off steam. And some codebases and some environments really do suck. But as a professional software developer, you owe it to yourself, your client or your employer to do your part to try and leave the a code little better then you found it. Regardless of the reasons the code is the way it is.

I've been known to get in some pretty heated debates with other senior developers on a project. But its always because I believe what I'm fighting for will make things better. I try to keep that behind closed doors. And when I loose those battles, I come out and do my best to make the given path as good as possible. Debate can be healthy and good for a project. Complaining is toxic.

How about this. Instead of complaining about all the technical debt your codebase has, try to think of one little thing you can do to help make it better. Just one little thing you can do with this current commit that can help make this codebase just one tiny bit better then it was before this commit. Then think about something you can do to grow upon that. What makes this code so painful to work on that you just hate it? How can you at least abstract that pain, and then share that with the other developers? Soon you will laugh about it and say "why didn't we do this sooner"? Be the snowball that starts the avalanche of good, and not the toxicity of complaint.