Technical Debt and The Big Rewrite

It is so easy to sweep things under the rug.

I’ll fix that comment later. One day, I’ll need to refactor this. Oooo this code is stinky, no time right now. No time right now. Just wish I had time. No time for this.

And then, kaboom.

You find yourself sitting there, in a pile of wicked code, wondering how it got that bad. You’re a good developer, how could you let this happen?

Let’s ask management for some budget to refactor things. Better yet, let’s rewrite it. We can do way better next time around.

STOP RIGHT THERE

You won’t do better next time around until you fix the very first problem – “I’ll fix that later.”

Every time you do that, you’re increasing technical debt, on a credit line where you probably don’t know the limit, but there is one, and one day you’ll find yourself bouncing promises like so many rubber cheques because you’ve run out of headroom.

How did the code get wicked? Don’t even try to shift the blame onto the code. You held its hand through every. single. bad. decision. one. day. at. a. time. And now you look at the poor thing like so much rotten fruit?

Oh, but you’re not the only person on the team, you say? It’s not your code that’s the worst, you say? You aspire to not be the worst person on the team? Maybe you should set your sights a little higher.

The big rewrite is declaring bankruptcy. It is saying, we give up. We can’t possibly repay this, or fix it. But please trust us one more time, we’ll do better! We promise!

When you declare bankruptcy in the real world, you are legally forced to take a time-out. You’re liquidated. The black mark sits on your credit bureau for years. You struggle for forgiveness in the financial world.

I think the same should be true of software developers. Think about that. What if when you give up on your code and suggest a re-write you have to go get a McJob for 7 years before you get to be a software developer again. Would you still suggest that re-write?