For those who don’t know, I work for Red Gate Software. I’m not a developer, but I work directly for the development teams so I spend a lot of time with them. This week I’m over in the UK, where they are headquartered, meeting with the different teams and discussing our products, their future, issues with them, enhancements, and all the rest. Suffice to say, I’m excited by the future.
But the really fun bits are when you see behind the scenes stuff. Red Gate is pretty well known for polished, intelligent, elegant UI design (yes, they keep me away from that stuff). Behind those pretty pictures though is code. And our developers are just like your developers, smart, capable, skilled, but still learning. And it’s those learning bits that are the most interesting.
Now, I’m not going to tell tales and get myself in trouble (I’m just recording everything for the massive tell-all when they inevitably fire me, HA!). But what I’m fascinated by is the fact that, despite the incredible skill of the developers here, and they really are damned amazing, they are all dealing with loads of code debt. Don’t know what code debt is? Sure you do. Everyone has it. Remember that time you thought that you could massively improve performance and maintenance by using a single lookup table for all the database rather than a large series of tiny tables? Don Peterson (he doesn’t blog or tweet, he just is, like Chuck Norris) coined the phrase Massive Unified Code-Key table (MUCK) for this design. Remember the intense pain it caused you? Remember how you then had to live with that design choice for years and years? Yeah, that’s code debt. Well, we have it too.
The thing is, you have to pay for code debt in some way. TANSTAAFL always applies, right? So you pay for it through maintenance over time, or you pay to replace it, but it doesn’t go away. Well, we have code debt that we’re paying to replace on several tools, and I’m wicked excited to see it getting taken care of. I’d say it’s a sign of maturity that an organization is not only able to recognize the debt, but is able to determine that NOW, right NOW, is the time to get rid of what had simply been a long-term irritant. Far too often we kick the can down the road and worry about what to do about it later.
Your homework: Identify some piece of code debt that you’re currently paying off. Determine the amount of pain it’s causing you. Calculate if that pain is increasing or remaining constant (it’s almost never decreasing). If it’s increasing, when will that NOW moment occur for you that you will absolutely have to fix it? Got all that? Cool. Now present it to your boss and see if you can’t pay off a little of that debt. It’ll be a great test of the maturity of your organization.
Here I thought I’d see an article about Bangers and Mash.
It is a timely thought however. I am currently rewriting an SSIS package to remove technical debt incurred by the author. Fortunately it is not yet in production so there is no long-term debt from it.
In other projects, however, we are grappling with much larger issues. One project is taking over ownership of a very central concept to our business and having to wade through all the crap that was never cleaned up before. Sometimes it just leads to pointless searches to learn nothing. Other times it leads us to things we have to clean up. And in some cases there is a choice.
But the team is taking the position that we have to be responsible whether we created the debt or not. If we don’t clean up those steaming piles, who will? History says probably no one.
Convincing management has not been difficult because we have good tools to search across platforms and we can demonstrate the cost of following blind alleys when it comes to maintenance. The blind alleys may not require maintenance but they require effort to do the research and decide again…which is just wasteful.
McCellan wrote:
> But the team is taking the position that we have to be responsible whether we created the debt or not.
I do this under two conditions.
I have been in the situation where a team has dead weight that constantly produces the same problems, and management would rather have someone follow after them and fix everything rather than address the elephant in the room.
In that case, I won’t touch it. Nothing destroys my job satisfaction faster than being the fixer upper for someone else. If they wrote it, and they are still employed with us and available, they should fix it.
The second condition is that I have complete ownership (look after) the resulting code.
Refactoring takes a lot of research and time; working out how something works, creating a new or better solution, handling migration, filling out all the documentation.
Now imagine going through all of that and then you get to hand all the fruits of your labor to someone else. Then they break it. Then it’s back to you because “you designed it”. No thanks.
I am also in favor of documentation, thorough commenting, and cross-training. I just also want to derive satisfaction from my work and I don’t get that if other team members, or procedures, let them nullify my hard-earned effort.
Grant – it is really refreshing to hear stories about companies prioritizing technical debt payments. kudos to RedGate!
You broke it, you own it. You wrote it you own it. You fix it you own it. You know more than the person who wrote it you own it. You have more time on your hands than anyone else you own it. You crossed the bosses eyeline when made aware of the problem you own it.
In short, you own it.
[…] Sausage Making - Grant Fritchey (Blog|Twitter) on paying down your technical debt this week. […]
>You broke it, you own it. You wrote it you own >it. You fix it you own it. You know more than >the person who wrote it you own it. You have >more time on your hands than anyone else you >own it. You crossed the bosses eyeline when >made aware of the problem you own it.
>In short, you own it.
Isn’t that a Slapshot song?