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.

my thoughts on technical debt

I'm calling bullshit on the "technical debt" brouhaha. Everywhere I turn I hear developers blabbering over technical debt. Developers crying about "repaying all this debt or we will be crippled.' Blah, blah, blah. Bullshit. 

Don't let the fear of technical debt stop you from building software that has business value. Ever. Its software. Its not steel and concrete. Software, is meant to be changed, modified, patched, and often thrown away. Yes, the results of some decisions will be more difficult to change then others, but it can all be changed.

Technical debt really only matters if your app is a success. And by success I mean that the app adds business value and has a reason to survive, be maintained, and grow. And by this definition, it is already a success.

Conversely, technical debt is forgiven and means nothing if your app ends up not serving a business need and has no reason to be maintained and grow. 

Every app has some technical debt. Most apps I work on have a lot of technical debt. Shortcuts, bad decisions, tightly coupled code, huge classes, little or no test. Often these decisions make my job hard and cause fixes and enhancements to take longer. But at the same time, I know that all these warts and problems are part of something greater. Something called shipped product. Something providing enough business value to someone somewhere that the app owners can afford to pay me to enhance them and make them better. And thats pretty special. 

I have hard drives full of pet projects and weekend work that was created in the spirit of minimal technical debt. But most of those projects are dead on the vine. Not because of their technical merit. But because they never got completed and shipped or didn't provide the business value I thought they would. Shipped code that is providing value to someone somewhere is a special thing. 

As professional software developers we go to conferences, read and write books on our craft, and constantly try to better our game. And all that is good and important. But none of that matters if there isn't shipped software providing value to people, and that is what matters most. 

I have seen more successful software in the wild providing business value that was written by people that just weren't that good at writing software, but figured out a way to ship and fulfill a business need, then I have pristinely written code. Its just fact. Warts and all, shipped code providing business value trumps pristine code sitting on a hard drive. 

So, lets help our clients or employers by making code better and easier to maintain. Because that is what professional software developers do. But lets rein in all the technical debt preaching, ranting and bullshit. It was a cute term for a day or two.

Build it. Learn from your mistakes. Make it better. Create value.