Break It Down: It’s Hammer Time for Technical Debt
Defining Technical Debt, Once and For All
If you’ve already read our first article about Technical Debt (and if you haven’t, you should), you can now call yourself a Technical Debt Investor. You have your Technical Debt Management (TDM) budget in place. You’re ready to go fix all that code real estate you own.
But then those pesky team members of yours start asking infuriating questions:
“Does this old bug qualify as Technical Debt?”
“How about the backlog for our CI/CD?”
“Making the logo blue, maybe?”
“Why is this cheese so good?!”
Is this Technical Debt? Is that Technical Debt? Blah, blah, blah, blah, BLAH!
So, once and for all, we need a solid definition for this whole deal. I’m going to share a definition with you. I’ve used it with my software teams for a long, long time now, both at B.Yond and before.
I’m not just pulling this out of my ascii. I have refined and perfected it over time. I’ve had ScrumMasters wailing, screaming at me that this made no sense (actually, they didn’t weep. They exercised their way through it). I’ve had Senior Software Engineers challenge my definition in its every nook and cranny. I’m still using it. That either means it works for me, or that I’m just too stubborn :-P
Let’s see.
Not is not (knot his knot?)
My first, grossly bombastic [cue loud music] filter goes a little something like this:
Everything the Product Owner (PO)/Product Management is eager to put in a backlog and/or pay for is NOT Technical Debt.
A simple test: Go to your Sales Team (yes, the scary people who come up with all that money you spend writing code from goodness-knows-where). Politely (very politely. Remember the money) ask: Is this something you could pitch? Would this sell more of our product?
If the answer is “No,” then congratulations! You’ve got Technical Debt.
Please note: If the answer is “yes, but…,” let’s not talk about it here. It’ll definitely fry both our brains. A subtle hint, though, is the concept of Product Debt. Old, crappy interfaces are good examples of Product Debt. But I digress…
What is what? (watt is watt?)
Okay, now that we know what’s NOT Technical Debt, you ask, how about explaining exactly what IS Technical Debt? I’m glad you asked.
My favorite way to define Technical Debt is:
Everything (technical) making the software maker’s life less efficient or less enjoyable IS Technical Debt
So, you’re now asking…what the Hadoop does that mean?
Let me respond to that by saying I was born in the land of cheese, wine, strikes, poets, Gauloises, and absinthe. As a result, I kind of live on the philosophical side of life (probably the absinthe). Even (perhaps especially) with concrete things, I just gotta abstract.
Starting now, I will talk in terms of time and space. It’s more poetic. Or maybe it’s the wine. I don’t know anymore. Anyway.
Let’s split Technical Debt into three distinct categories:
1. The Past
This is what people classily refer to, and easily understand as, classical Technical Debt: it’s all the little decisions we’ve made in the past, decisions we now regret, or at least wish we made differently in our software.
This is our refactor debt.
Once upon a time, we neglected/chose not to …
…update the libraries we all depend upon.
…split that Huge Object with a lot of functions and a lot of code.
…remove all those security vulnerabilities ceaselessly festering in our code.
…write that crazy crontab rule correctly.
…write a full mock-up for that deeply complex integration test.
…centralize all the redundant configurations into a single file.
…fix the bad test that we listed as “ignore.”
…fix the build pipeline slide into getting longer and longer, because it was working and we didn’t want to touch it.
And that, my dear, is slowing us down more and more each passing day.
Now, let’s make something very, very, very, very clear:
Bugs are not Technical Debt
I know your Product Owner/Product Manager will try to convince you otherwise. Nope. That’s on them. If it’s a bug (a feature that doesn’t work “correctly”), then it has value (you called it a feature!), and they’ll have to make a choice about fixing from inside “their” budget (the product backlog).
That’s the first type of Technical Debt. Now, let’s talk about…
2. The Present
This part will be more attractive to those agilists among us.
Welcome to practices debt.
As Software Crafters, ask yourselves:
…How effective are we at code-review (you do do code-review, right?)? How constructive and productive are the tools we use?
…How nice are we at pair-programming? How amazing are our video and shared keyboard/mouse options? How easy is it to book one with a fellow team mate? How eager are we to actually work with them?
…How amazing are we at continuous integration? How often are we adding integration tests? Do we know how to write a good mock-up?
…How wonderfully pertinent are those integration tests? How maintained — and maintainable — are they?
…How strong are our security practices and version update processes?
…How excellent is our penetration and performance testing?
List and prioritize everything that can make you better at those practices. Every effort that can make you better, day-by-day, you should consider.
Try new CI/CD tools. Try new ways of pair-programming for a day. Approach your tests using Domain-Driven Design. Experiment with recording yourself singing in front of your chatbot to allow voice command injection. And so on.
Now, that’s all good, but what about…
3. The Future
That last category of Technical Debt is truly the most insidious. It is the one we know we shouldn’t neglect, but we just can’t resist doing just that. It’s the kind of Technical Debt that separates generally good software crafters from consistently excellent ones.
This is Knowledge Debt.
If you think about software creation (or “engineering,” if you want to be all pretentious about it) as a craft, then you know you need the right tools. But you also need the craftiness. In knowledge work, our knowledge is a tool (hence the name!)
And that’s why, like every good woodworker or nail-hammerer, you need to at least try and develop a basic understanding of what’s in there and what’s not:
…Never used containers? It’s 2018, dear. Time to fire up that Docker command line.
…Don’t know what all the fuss is about Functional Programming? It’s probably a good idea to get some examples running and try to write some yourself.
…Haven’t launched a Spark Job in all your living life? You just know your life will not be complete until you do.
…Looking forward to serverless? Tomorrow is always tomorrow, never today.
…Want to make the move to React? It’s probably a good idea to do some work using it before you decide to move your 2 Millions lines of AngularJS Javascript code…
Some companies may see this as a waste of time. If yours does, I’m sincerely sorry for you. You should probably make some more hard life choices, and all that other jazz.
Some companies may feel like they don’t have time for it. You might think the same. And that’s where I am always the ultimate joker about “not having time”: in the final analysis, time is all any of us have. Make time. That’s why we created the TDM budget… mmkay? (see our first blog post if you don’t know what I’m talking about)
Like everything else, Technical Debt needs prioritization. One-by-one, you should tackle your pain points, beginning with the one making your software bleed, up until the time you arrive at a small inconvenience.
At the point of the small inconvenience, you should be prepared to look into that category of Technical Debt and make a choice: is it more important to learn about Scala than to fix that missing comment about the integration test? That’s for you to know.
But please, don’t neglect your skillset. Remember: it’s what they pay you for…
Technical Debt Everywhere!…
Using this definition to filter out your activities with your teammates, you can build up a pretty damn good backlog of Technical Debt items to confidently tackle.
Now that you are joyfully looking over the list of everything that you can do better, you’re going to ask: Just how do I actually do it?
Maybe you use Scrum, so now you’re all, like: “But Bruno, Bruno, how do we follow a Scrum process and implement this?! This is impossible!”
You’re jumping around and pointing your finger at us: “How do you do it at B.Yond, huh?! Tell us!” (Yes you are. We know you are. We’re building AI, remember?)
Ahhhhh. You excitable agilist! It is not easy, but it is very possible. B.Yond will give you the secret.
But that’s our next story! Tune in again, won’t you?
