What is technical debt, how to use it, and how to avoid it with Alex Omeyer from Stepsize

Victor [00:35]: Alex, welcome to the show.

Alex [00:36]: Thanks for having me Victor.

Victor [00:38]: What is Stepsize? What do you do?

Alex [00:41]: Yeah. So Stepsize is a tech company building a developer tool, specifically dedicated to building the connective tissue between the code editor and all the tools that engineers have to use all day every day. And we just happen to have started with issue tracking, which enables a whole bunch of new workflows and use cases. One of which is to use it to track and prioritize things you want to improve in your code base and deal with technical debt, which is why I’m here today.

Victor [01:10]: Oh, totally. Yeah. So let’s put a definition out there. What is technical debt?

Alex [01:16]: I like to say that technical debt is code that you’ve decided as a liability essentially. And I’ll try to expand on that a little bit. All that extra work that you feel is unnecessary. Yet you have to do to get your software out of the door. It takes many shapes and forms. It could be bad code. It could be good code that is no longer appropriate. It could be, just a change in priorities that doesn’t match your expectations as to what your business should be doing. And therefore your code base is no longer appropriate and you need to do something about it.

[01:50] So it isn’t necessarily the result of engineers doing a bad job. You can think of it as entropy in your code base if you ever tried to spin up some old Python project, only to see every dependency break and have to spend a few hours fixing the thing to get it going again. No one’s touched it. No one’s fault, but they’re still technical debt in there.

Victor [02:11]: Right, yeah. That definitely never happened to me. And so why does good coat matter because you said that a part of that could be bad code. Right. And I want to expand on that a little, and I understand that sometimes this depends on the stage you’re at, right? You said it could be good code today, but it could be bad code tomorrow if my business priorities change or my scale even or whatnot. But probably there’s also objectively bad code. Is there something like that?

Alex [02:41] Yeah, definitely. So sometimes people use the term technical debt as a shortcut for bad code. And that’s very different, because if you’re not following best practices, if you’re not doing a good job, building, clean, readable, extensible code, then you are more likely to have problems dealing with it. And maintaining it later down the line. That being said, any line of code that you write comes at a maintenance cost. And the maintenance cost is higher for bad code than it is for good code.

[03:14] Mountain Fowler has a great technical debt quadrant as he calls it. I won’t describe it, go to his blog and check it out. But effectively he says that if you’re going to take on some technical debt, it needs to be prudent and deliberate. Prudent because you didn’t take on too much. And it’s not a ridiculous thing that you’ll never be able to deal with. Deliberate because you made the decision. You didn’t just happen to pile it on without knowing. And that’s what tends to happen when you write bad code.

[03:44] You asked about the importance of sort of a clean, healthy code base. If you accumulate too much technical debt or let your code base get unhealthy, you’re going to end up with loads of productivity issues in your engineering team, which means you’re not going to ship features as fast for your customers. You’re going to end up with loads of quality issues in your software, which means there’ll be plenty of bugs or security issues and all that kind of stuff for your customers again, and also your engineering team’s morale is going to go down the drain because no one likes to spend ages wrestling with technical debt that they know they should have dealt with if only the business had let them do it. So these are the three areas where I see businesses get impacted by technical debt.

Victor [04:33]: Yeah, it’s a classic engineering versus product, push versus refactor. And I guess that’s exactly this model of technical debt where you don’t have to do it now. You don’t have to pay it back now. You didn’t borrow against it in theory. Saves you money, but it comes at a cost. And what exactly is that cost?

Alex [04:58]: The cost of technical debt is what I was saying at the end of that last answer, is productivity, quality and morale. And I’ll give you a few data points on each of them because we often survey engineers in our community to ask them questions like, Hey, how much faster do you think you would go if you had technical debt under control and two thirds of the respondents in this first survey, unless we’re talking a couple hundred engineers said that they thought they would go twice as fast if they had tanked that under control and 15% said three times faster.

[05:33] And anecdotally I’ve asked directors of engineering at very serious software companies who were into the five X, six X, eight X. So that’s the impact that it can have on your productivity. Stripe has a really good report called the developer coefficient, Google it, have a look, it’s written by Stripe. They also did a survey of a lot of engineers where they found that and I may be misquoting here, but engineers effectively spend a third of their time dealing with technical debt and its consequences. And then on the next point, I think, that same survey asked engineers if they thought that technical debt could be the root cause of bugs. And to then the answer is duh, right? So pretty much everyone knows that if you have too much technical debt, you’re going to end up with bugs and extra, maybe more serious problems.

[06:23] And then when it comes to engineering team morale, again in a separate survey, we asked a few hundred engineers if they’d ever considered or had quit a job because of technical debt in the code base. And 51% of them admitted to have had this thought to outright quit a job because of tech debt. So all these problems that we have around developer shortages and chart in the team, the average tenure of an engineer is like 12 to 18 months in a company, which is not a very long time when you think about it. These happen in a big part because of technical debt as well. Not just of course, but in a big part.

Victor [07:01]: That’s actually really bad so to speak when you have technical debt. So not only do things go twice or three times as slow, according to your studies, but also people might just quit. And I guess it’s not even that things move substantially slower, but in a calculatable predictable way, but it’s like totally unpredictable as well, right?

Alex [08:12]: Yeah, that’s a great point because if you think of tech debt as entropy in your code base and all this extra complexity that you have to deal with. Picture any exponential curve and try to predict where you’re going to be on that curve. You’re off by this much, all the way at the top or all the way at the bottom. And that’s the issue that you’re dealing with when you’re trying to get any sense of timelines or predictability in the way you’re working on a code base that has too much technical debt.

[08:39] I’d like to clarify as well that technical debt is not this bad and evil thing. To think we’ll talk about how you can take some on for extra leverage so long as it’s prudent and deliberate, but if you have too much of it and it’s not prudent and deliberate, you can end up in that situation.

Victor [08:55]: I like that point because as you mentioned, like most people probably just run into having technical debt and then they suddenly realize that everything’s harder, deadlines are being missed, customers complain, but how can I make that deliberate decision and really say, Hey, I want to save some money. I understand the consequences. And when should I then really start paying it back? When should I make that decision? Because I think it’s super painful at any point in time.

Alex [09:27]: Yeah that’s a great question. There are actually a lot of things to consider. One of them could be the stage of the product on which you’re working. So if you’re working on something that’s very early stage and unproven, you’re probably better off taking on some technical debt to put it in front of the target audience to get some feedback and iterate on it. If you’re pass that line where you found some semblance of product market fit, the things that you know are here to stay, ideally should not contain too much technical debt, and that’s where you start paying some back.

[10:01] So if you think of it in terms of startups that may often happen after the series, A. Maybe series B where they have a product that is gaining traction, they have customers, they can’t just bend the thing, which is the easiest way to deal with technical debt is throw it away, all the tech [10:16 inaudible]. We have to support and maintain this thing because you have customers who rely on it and you need to do that at the same time as shipping features. And so that’s the balancing act that you have to figure out is on the one hand, the pressure to ship features, which is very directly tied and obviously tied to growing revenue, growing engagement, all these metrics that matter at these companies.

[10:41] And on the other, you’ve got maintenance work, which sounds more boring. And it’s a lot harder to draw a straight line from maintenance to revenue. But at the end of the day, it indirectly impacts pretty much every aspect of your company when you think about it. So there are ways to define your technical debt budget for your sprint, your month or whatever period is sort of predictable for you. Effectively the way you do it is you decide on your current business priorities and it could be shipping features. It could be the security of your platform, the speed at which your website loads, your engineering, team’s productivity, your morale.

[11:22] You have these priorities and you find ways to deal with the technical debt that gets in the way of these priorities. So one obvious one is when you say next sprint we’re going to be shipping features A, B and C, and you’re able to go, okay, this will have us work in code XYZ. What are the problems in this code that will impact our ability to ship these features or the quality of these features or whatever business priority you care about, then you go, okay, let’s scope them out, these improvements like you would any feature work and have it go through your usual development process, if you will, exactly like you would for feature work.

[12:00] And so let’s say for sake of argument that you can ship a hundred story points in a sprint and you end up with 20 story points of improvements that you’d like to make to your code base to clear the way for this business priorities. You’ll take that budget for the sprint is 20% to the sprint. And you want to do that on a regular cadence because I think I’ve never seen a company really succeed when they stop everything and just go, let’s deal with technical debt and then get back to these business priorities later, namely, because it usually, you can’t boil the ocean. You can’t deal with all of your technical debt at once.

[12:37] And while you are dealing with your tech debt, you’re also building software based on your understanding of the problem you’re solving right now, give it a few days, weeks and months, especially if you are an early stage company, then understanding will change for your code base if you leave it unattended will not. And so that’s why it needs to be a continuous thing while your business evolves.

Victor [13:02]: And that makes a lot of sense, because as you say, there’s never a good time to stop and rebuild or take care of things, but it just gets worse if you push it off. So in a way just dealing with it in a continuous way is probably smart. I’ve seen various ways. Probably two of them or whatever part of the code we’re touching to change features. We will refactor or even separate teams that a new one takes care of somewhat of every factor or rewrite, I don’t know, depending on probably the size of the company. Not sure what’s the best way, I guess that’s super individual.

[13:38] Now, maybe more speaking about the bad code in the sense of objectively bad code or even a non-fitting architecture for the current stage or scale of my business. How does a non-technical founder understand if their app might have a bad code base? How do I realize that?

Alex [14:01]: Maybe it’s time to use an analogy? And one I like to work with is that of a professional kitchen. If you’re just shipping dishes all night, without any regard for cleaning the surfaces, cleaning the, the, the pots and pans, as you go, making sure that everything is nice and sanitary, you’re going to get shut down because you’re going to make someone ill. Also, at some point you just won’t have the space or equipment to keep shipping dishes. The same goes when you’re shipping features all day, every day, without any regard for that maintenance work.

[14:38] And the best way to know the situation is to ask the people in the kitchen. So to talk to your engineers about it, and one thing to remember, and maybe it’s a bit of a stereotype, but it’s interesting nonetheless, is engineers love to build things properly.
And if you listen to some engineers, they’ll tell you that everything needs to be fixed in the code base. And so that’s where your role comes in. You need to understand what is actually impeding your key business priorities, and then say, look, I know this other stuff is on fire, leave it for now.

[15:16] Maybe you’ll come to it someday, but deal with the things that are in the way of priorities, A, B and C, because this is the stuff that we’ve decided matters. And that’s very important because if you just listen to engineering, they’ll probably pull you too much in the maintenance direction. If you just listen to products, they’ll probably pull you too much in the let ship features direction. I’m aware these are stereotypes and oversimplifications by the way, but that’s kind of the problem you’re facing. And so if you have forums for your engineers to talk about this stuff, if you have tools like Stepsize for your engineers to report these issues that they come across in the code base before they start causing problems, then you’ll have ways to find the stuff that’s in the way of your key priorities.

[16:04] And to say slow down, let’s not deal with this stuff over there. Let’s deal with this over here, because it’s important. I’ll give you an example. You may have part of your code base that’s absolutely terrible because some non-technical founder who learned how to code built it early in the company’s lifetime, like I may have done, but it’s not causing any bugs. It’s still humming away in a part of the code base that no one’s going to be working on for the next six months. So why bother? You’re not going to go deal with that when you could be refactoring, I don’t know your payment system that is not billing your customers properly, for example, which is maybe one of your key priorities at the moment.

Victor [16:46]: That makes a lot of sense. Probably the hardest part, especially for a non-technical founder is understanding which actually impact what, and then being able to make the right decisions. But then you should probably work with, and listen to your lead developer CTO or whoever you might be working with, or worst case, get an external consultant on that.

Alex [17:10]: I would add that your job as a non-technical person who influences the staff is to be clear about the priorities of the business, because your engineers will be able to find the things that are in the way of these priorities, right? They typically don’t need to be overseen. If you clarify what it is that matters, they’ll be able to prioritize the right things.

Victor [17:30]: Yep. I guess clear communication, clear your goal setting and making sure everybody understands the business goals, the mission long term, but also short term, these are the things we want to impact over the next three months. Like what’s standing in your way to do that I guess, that’s the right approach.

Alex [17:51]: Exactly. Exactly.

Victor [17:53]: So generally speaking, and obviously it varies from stage to stage, but speaking about best practices, what should developers be doing that produces good code and a normal maintainable code base?

Alex [18:08]: There are some classics that everyone would’ve heard about, things that you can do to level up as a team, whether it be code reviews, some people like to do pair programming, there’s tooling. Classics like linters or code quality tools that you can use to flank some of these issues. There are things around your development process. And if you have retros on a regular cadence that are properly run to surface any issues that you might have in the development process, and then you actually allocate time and resources to dealing with these.

[18:43] Over time, you’re going to keep leveling up. And at the end of the day, I like to think that the way to summarize the problem that they’re facing in the engineering team is that they, and that’s a concept called sustainable development. That’s part of the 12 key principles of agile, is that if you manage to level up faster than the complexity of your code base increases, you should theoretically be able to ship at a very sustainable and predictable pace, despite your code base getting more and more complex. So that’s the idea.

Victor [19:15]: Yeah that makes a lot of sense. That’s a great one. Now maybe let’s talk a bit about Stepsize. How does Stepsize in particular help engineering teams tackle technical data? You mentioned it helps point out where the issues are, but maybe give it a bit more details.

Alex [19:35]: So we’ve acknowledged that the engineers hub should be the code editor, but it’s not right. And that causes all sorts of problems if we focus on technical debt. Because people typically try to track things they want to improve about their code base in a backlog, in a tool like Jira, let’s just pick on Jira, but it’s the case with any generalist PM tool. These issues are totally divorced from the code they relate to, which means you can’t do this exercise that we spoke about earlier of saying, we’re working on features, ABC in code X, Y, Z, what are the issues in there?

[20:12] So the issues are totally divorced from the code they relate to. And with Stepsize, engineers can just select right there in their editor, any snippets or collection of code and create an issue, a normal issue that lives in their issue tracker as well, but is also linked to the code it relates to. And so all of a sudden, this sort of ongoing maintenance and improvement of the code base can become part of the conversation that you have with product in sprint planning, in any of the usual grooming sessions or any of the usual ceremonies that you have around building software.

[20:48] And I told you, that’s one of the use cases to flank things you want to improve in the code base. But when you think about it, if stepsize is a way to leave annotations in your code, you’re also talking about replacing all kinds of code comments with something strictly superior that has all these multiplayer features around commenting and tagging people and assigning them and resolving subtasks and so on. And you can also use these annotations as a way to document some quirks in your code. Like, Hey, this piece of tech that we’ve decided to keep it around for now, but here’s why we’re doing it and what we’ll do about it later.

[21:24] So the next person who comes around and sees that code can have this information and not go down the same rabbit hole for example. Another use case might be to flag top coding standards that you would like the team to follow, or even pull code that you would like the team to look at and do a sort of a mini review in there. And so what we found out is that by bringing this integration to the editor, with the issue tracker, we’ve enabled all these new workflows that were previously completely impossible and extremely valuable for these engineering teams in terms of helping them collaborate on that code base and keeping it healthy.

Victor [22:04]: That’s super helpful. Go check it out. Stepsize.com and how did you get that idea? How did you start the business?

Alex [22:13] Oh, wow. So I’ll give you, how much time do you have? Victor [22:20]: As much as you need.

Alex [22:23]: I’ll give you the summary. So I have three co-founders who are originally mathematicians and data scientists, and the first insight behind stepsize was, Hey, there’s a lot of data created as a byproduct to software development. I wonder what kind of cool stuff you could do if you had access to that data. Some of the cool stuff would be applying AI and machine learning to some of these development workflows to try to automate them. But before that, there’s a lot of value you can deliver just by bringing up the right information in the right place at the right time, etcetera.

[22:57] And we thought that in order to deliver on that future promise, we would need to build a product that is so valuable that engineers use it all day every day. And that leverages this kind of data set, this context around code to help them do their jobs better.
And we went through many iterations of different ideas for products that would have this potential. And in, it was June of last year we shipped the first version of this product that I described, which quickly took off. And so clearly, this idea that the editor should be the real hub for the engineer, but realizing all the ways in which it’s not, and all of the opportunities that they’re missing. I was talking about these new workflows that we enable, all of that was a really big deal for our users and customers. And so we doubled down on it and here we are.

Victor [23:53]: Cool, amazing story. Well, thank you so much for being on the show. Where can people find more about you?

Alex [24:02]: So please go to Stepsize.com. You can try the product for free as well. You can find us on Twitter at stepsizeHQ, where we share a lot of content relating to code quality, code based health, technical debt, some good memes as well. And if you want to get in touch with me, I’m on Twitter as well at Alex Omeyer.

Victor [24:24]: Awesome. Thank you so much. Been super helpful. Alex [24:26]: My pleasure. Thanks Victor.