Wellfire Interactive // Expertise for established Django SaaS applications

Previously, we talked about tests. Great tests, no tests, slow tests and bad tests. Today I want to talk about technical debt.

Technical debt is a really big topic and we’re not going to cover everything there is to cover about technical debt in five minutes or so.

But I did want to talk about what it is, so we kind of understand what technical debt is as a concept, why we find technical debt, conceptually what it looks like in a Django application and get an idea of what some strategies are for tackling it.

So, first, what is technical debt? Well, technical debt is basically changes you have to make to an application, or that you’re going to need to make to an application, that are the result of decisions made in the past.

Maybe changes that were not made, that were kind of punted off to the future, or changes that were suboptimal, or due to changes in, you know, even things outside of the code base like requirements or the landscape for the business. The business had to pivot and you’re left with some modules that really need to be reworked to work with the way that code needs to work now.

So, there’s these preconceived notions that technical debt is this awful thing with, you know, these lines of code that are hundreds of characters long and, you know, this awful variable names, just terrible programmers were involved and it just this was the garbage that now needs to be cleaned up.

And that, that certainly that, that would sound like technical debt to me, but that’s not representative of what technical debt is.

Technical debt is the manifestation of opportunity cost. Maybe that’s not what you want to use, you know, with your boss or with clients, but this is it’s the result of past decisions it’s the result of, you know, code changes that maybe you didn’t have the bandwidth to make in the past, and expected to have the bandwidth to make in the future. And, if you do, then you can make them, and if you don’t, these just accumulate just like debt. If you take on more debt than you can handle, this becomes a problem because you can’t pay it down and you’re left with this burden.

It’s a very difficult concept image to sell to management. But, the reason it’s a problem is because it usually represents friction in the rest of the process. So, it’s architecture that doesn’t really fit what you’re doing. It’s names in your code base that are confusing because they represented how the world worked in one iteration of the program and when business requirements changed it needed refocus and you’re still stuck with all of these names that cause confusion because they represent, they don’t talk about the same things that your code works on now.

So, this is friction. It doesn’t necessarily make your program run worse, but it makes it much more difficult to make changes to the application.

So, what does it look like a Django application? Well, I think if you think about names, already that’s one of the big things you’ll see is you name models after, after things in the domain and something changes. And now you have these models that are all named referencing something that maybe doesn’t exist anymore or it’s been used for something else, and so it causes some kind of confusion.

It can be apps that become bloated. You know, you have this one app and it was designed to do one thing and eventually everything in your business is this one Django app. Basically, you know, this one module. And it’s hard to test, it’s hard to pull things apart and work on one little piece at a time. That’s really common. That’s one of the most common manifestations of technical debt in Django projects.

And there’s, there’s more than that, too. It could be dependence on, you know, architectures that are a date, or third-party libraries, you know, referenced in our newsletter, this whole Pony, you know, you’re referencing these libraries or third-party APIs that become deprecated or change and you have to make these changes, too. That’s a really form, common form, of technical debt in a Django project.

So without going into great detail about how you address this, you know, you need to have a strategy for addressing it kind of in an ongoing basis, usually. You typically will, kind of, see what you can do to assess what the state of the application is, where do you where can you actually identify technical debt, and what kind of levels of technical debt.

So, if you need to pull everything apart, you know, because it needs to work for a new domain, that might be pretty significant, whereas changing certain names might be just an exercise in refactoring. You know, changing something like model names might be a little bit more advanced than that, you know, it’s not like a one, it’s not like a ten, but it’s a somewhere in between because you want to do this in kind of an artful way that doesn’t destroy the database when you’re making these migrations.

So, you start with this plan, you start looking at the, the, kind of, itemizing the things that you’ve called technical debt and giving them some sort of ranking, and then you start approaching these. Typically, the lowest hanging fruit, kind of approaching a snowball method is usually the best way. If you have to pick strategy, it’s a snowball method. Pick the little, easy things, get those done, and start building momentum toward the bigger things.

You can also, I mean, if there’s something that is a big driver, it’s really this one, big, hairy mess, then take care of that first, but, but you have to, that has to be something that is warranted by your project.

So, that’s, that’s an overview of what technical debt is. You know, why it’s important, or why it can be bad, and maybe why it’s not always bad, what it looks like in a Django project and hopefully some, you know, a high-level strategy for taking care of it.

If you have questions about how to approach that, let’s say, I mentioned with Django model names or extracting, you know, or piecing apart one big model of the app, go ahead and ask us questions. Put them in the comments, or on Twitter, or email ben@wellfire.co and we’ll be following up, as well, in future videos, and our blog, with some strategies for taking care of technical debt.