John

Welcome to Pragmatic Leadpodcast, your hosts are Alex Bachuk and John Masse. We have conversations with folks throughout the tech industry to get real world perspective on how people make things happen for their careers and businesses. Check out pragmatically.com for more content, just like this.

Alexander, thanks for joining us. Why don't you just kick us off? Tell us a bit about yourself. Yeah. Okay. I wonder how far back I should go. But first of all, thanks for having me. I'm excited for the episode. So my name is Alex. I'm an undercover Frenchie living in London, I am building a company called step size with my brother and three of my my closest friends, that, you know, we've grown over the years sort of started in at the end of 2015. And the product we're building is all about helping modern engineering teams manage technical debt. So that's, I think, what we're gonna be talking about mostly today. Yes, absolutely. So we wanted to take just a minute first to dig a little bit into step size. It says so step size is to measure prioritize tech debt. What is step size? And what problems are you working on? Like? Can you give us a little bit more description? or How would you describe how? Oh, yeah, sure. Yeah. So, you know, I spend most of my time speaking to the best engineering teams that I can find who will have me who will tell me about how they deal with technical debt. That's how we met, right. And a lot of the teams that I speak to often tell me that they find it very easy to draw a straight line from shipping a new feature to some positive impact on some company KPI, you know, we ship this thing we make more money or engagement goes up or whatever it is, but they have a much harder time doing the same thing with any piece of debt in their codebase that they want to fix, you know, how do you draw a straight line between maintenance work and good things happening for the company. And that's what you need to be able to do to prioritize the right technical debt, which is to say, the debt that if cleared, really moves the business forward. So you know, we built this SAS product that integrates directly into the engineers workflow to make it super easy for them to track the debt they come across day to day, and most importantly, to quantify the impact it's had on the business. So that might be in terms of engineering hours lost, or product quality issues, like bugs or outages, all this kind of stuff. And this is the data, they need to prioritize the right tech debt and eventually understand that positive impact it's had on the company when they fix it, right. So we also plug in directly to plug plug directly into tools like JIRA to ensure that maintenance is always part of the planning conversation and other sprint ceremonies, because tech debt isn't just engineering problem, right? There are many different stakeholders involved. And we help them paint that picture. Yeah. And you took me through the software. Congratulations. It looks fantastic. And I think he I think you're right about the it does feel like you're trying to get in line with where the engineers are working in the moment to capture the story as close to where it is as fast as possible, so that they're not having to write a whole lot of additional documentation jump out of there. Maybe they're in a flow, and they want to capture something immediately. So my question I have is, did step size always look the way it looks today? Or are there kind of some interests? Like are there some lessons that you've learned while developing the product about how teams are managing their tech debt? Or the conversations they're having around it that you think would be interesting? Oh, yeah. I mean, you know, we started, like I said, early 2016, right. So we've been through many iterations of different products. It wasn't always about technical debt. But what we were building was always about helping engineering teams ship better software faster, regardless of what we were building. And, you know, the thing that you mentioned about being integrated in the DevOps workflow was one of the lessons that we learned very early on, you know, a lot of the teams that we speak to have a homemade solution where they might have a big backlog of all the technical debt issues that they came across in their codebase in some tool like JIRA. And the issue with that is generally speaking, JIRA is a great place to put things that need to get done, but not a great place to put things that need to be monitored. And, by definition, take that as a bit of both, you know, you have take that across your entire code base, but you don't need to boil the ocean and fix the whole thing. In one go. You need to identify the subset of stuff that's going to be in your way for the immediate business priorities and the rest of the stuff that doesn't cause that many issues. You know, keep

Alexandre

I on it, but you don't need to fix it now. And then, hence why we decided to be integrated in the in the engineers workflow and have this separate place this web app where they get or consume the information they've tracked and use it as sort of a staging ground for what goes into JIRA once they've decided to deal with it. But that's just one of the lessons, you know, I mean, we think at some point, we were building a sort of specialized search engine, for software engineers under the premise that, hey, you know, there's all this, engineers spend a lot of time googling stuff. And if we can make this process better, we'll have a big valuable business that helps them a lot. And then we realize that commercial engineers who work within companies don't necessarily find all the answers to their problems on the internet, because the data that relates to their private company, their private company's code base isn't out there, it's inside. And so then we started looking into ways to leverage all this data that engineers create as a byproduct of the work they do. So things like a JIRA ticket that describes the intent behind the code, the commit messages and all the data that you have in Git about the history of the codebase you're dealing with, and much more to try to put together a product that we said, it wasn't exactly that, but it kind of helped you automatically document your code. So for any snippet of code in your codebase, you could find the data internal to your company, relevant to it to understand what's up with it. And then, you know, the problem we were trying to solve with that product was, we saw that engineers spend most of that time trying to understand code. And we figured, well, the problem, the reason it's so hard to do is because of a lack of documentation. So let's try to fix that. But actually, what we realized is that the reason code is hard to understand is often because of technical debt, you know, imagine the perfect piece of code that's perfectly written, it should be fairly easy to understand, you know, and that piece of piece of code matches your understanding of the problem that you're trying to solve. everyone's on the same page. It's not exactly the same thing. But you almost read it like pros, right. And that was not the case in the companies that we spoke to. And so we started looking at the problems with technical debt, like, why is it the technical debt is so hard to deal with, and there was sort of a fork in the road, you know, at first, we saw that people were having a hard time measuring tech debt. And we interpreted that as they didn't have metrics to identify where the tech debt in their codebase was. So we built a prototype that was computing like metrics, like the levels of ownership and the code, the pace at which a piece of code is changing the churn rate for a piece of code, we'd look at static analysis and classic code quality metrics, to give a rating to the quality of your code. And we, we try to identify hotspots in your code base like that, and tell you, hey, this piece of code over there is looking pretty bad, you should do something about it. But then when people looked at the data, they were like, I know, it looks bad, but I don't really know what to do about it. And most importantly, I don't really know how to convince the company that we should do something about it. And that's where we went for, you know, I mentioned the fork in the road, the other leg of that fork was you can think of it as metrics versus people quantitative data versus qualitative data. And that's where we started building the product that we have today. You know, it's less than a year old, I think, where it was built on the premise that if you speak to an engineer about their code base, or at least the parts that they know, they'll be able to tell you, this is what's messed up with it. Right? I know, I know that this thing is messed up. The thing that they have a hard time doing is explaining why the business should care about the fact that it's messed up. Right, right. And it's why we built the product that we have now. So I'm sorry, that was a super long explanation. I skipped some bits as well. But hopefully, you see, you see the the trail of thought here?

John

Yeah, no, I think you did a great job taking us. So something that I think is different from what I saw with step size from other kind of like, out of the box status, static code analysis tools, like sonar cube comes to mind is you have the human interaction you're not. It's not you're not just relying on what you're what the software can kind of glean from what exists. But you are really relying on humans to control document and participate in like really creating a real understanding of where the people see the problems.

Alexandre

Yeah, that's exactly right. And you know, Ai, tools like sonar cube, or code scene or Code Climate are invaluable. They're great at what they do write they're also very complimentary to what we do. I mean, I can totally see ourselves building integrations with these tools later on, so that we can say, hey, people have identified this issue with your code and By the way, here's the code quality score from Code Climate. Here's what code seed says about how much activity this code is seeing and get, here's what century has to say about the errors that you have, that this code relating to this debt is throwing is just that there's a gap in the market on tooling. where, you know, the business context relating to the debts is just as important as the quality of the code, for example, right?

John

Certainly, we need to be honest with ourselves to as engineers, like how we want to spend our time. And sometimes it's like, something might feel bad, but not might not actually be relevant in the moment, maybe it will come someday, it's not that the ideas and thoughts are irrelevant. So before like, so Alexander, I'm really excited about some of the stuff we're going to talk about specifically around tech debt. But really just for the sake of kind of completing our narrative with with StepSize as a product, you are talking seems like you have an opinion on how to connect tech debt to business decisions. How do you guys see that bridge happening? Like, what do you what are your ideas there?

Alexandre

Yeah, that's a giant topic, I think we need to talk a bit about what impact tech debt can have on a company, if not dealt with properly, because that that will make it easy to explain. You know, there's sort of three main reasons to get a good handle on tech debt, number one, to increase engineering productivity, right? If the code is well maintained, we'll ship fast

John

Well, well, well, yeah, ship faster, but there's a real dollar, like value can just like I don't, I don't think we talked about it enough that we are paying people salaries.

Alexandre

Exactly. Right. That's exactly what I was getting to is like, you know, you want to increase productivity, your engineers are probably the, you know, rightly so Highest Paid people at your company.

John

It's the biggest expense of the of our organization, right. So why? Because to optimize, exactly, resource.

Alexandre

Exactly. And, you know, like, there are many, there have been many attempts at trying to measure engineering productivity, it is super duper hard, you know, I mentioned how you can use get data to look at to try to sort of find hotspots in your code that might have or might cause bugs in the future. Some products use this data to try to measure the productivity of an engineer, you know, this is how many commits they push this is how quickly they merge their pianos or that type of stuff. And it's interesting, but I find that it often creates the wrong incentives, you know, it's really hard to measure productivity for such a creative job. So anyway, that's a totally different topic. But you know, reason number one, increase productivity engineers, highly skilled, highly paid people, why would you not want to optimize that, right? But it's hard to draw a straight line, again, between these things. Number two, to improve product quality. You know, if you don't deal with tech debt, you'll have more bugs, you'll have more outages, you'll have more support requests, your customers will end up leaving for competitors, or at least that the risk will be increased. So again, there's a real money component here, right? If you manage to draw a straight line between a piece of debt and the product quality issues that it causes, and then estimate how much money it is costing the business, you're doing a good job of building the business case for this piece of debt. And then yeah,

John

Just jump in there. Do you feel like you're helping engineers bridge that gap today?

Alexandre

Yeah, that's the it's not perfect, right? It's not finished, we still have a lot of work to do. But that's, that's our goal, right? where I'm headed with this, you know, sort of telling you about the impact that that has on the company is that when you want to convince the business, that it should be investing engineering resources into maintenance work, as opposed to investing these engineering resources into shipping features, you need to be able to make a compelling business case. And step size is here to help you with that. You know, the third aspect, the third reason why you might want to be careful in how you manage technical debt is that it has a very big impact on engineering, team morale, right? People who are engineers are here to ship and build cool stuff, they can't stand spending a month, just, you know, going through a ton of red tape and a ton of problems to deploy a tiny change on the footer of the massive company's website. You know, that's what their lives look like, they're not going to be particularly happy and they end up leaving the business. I mean, there are a few studies that have shown that it's one of the biggest reasons for employee churn well, so

John

why why wouldn't we want to care about the general quality of life of what it means to build I think like, building software is almost like the secret world where imagine like we just see the outcomes but we don't imagine what it what what the people participating and actually creating these things are going to be okay.

Alexandre

Yeah, it's fascinating you when you start looking into To the sort of hidden complexities of what we do, that's when it becomes fun actually is dealing with these complexities. But if you ignore them, that's when you end up with, with tech that, you know, I've heard tech that described as the result of entropy in your codebase. So it's totally inevitable, you know, you're gonna have to deal with it. I mean, even if you just left your code alone for two years, and came back to try to spin it up, every dependency is gonna be deprecated, you're gonna have a hard time just, you know, just running it. So even if you don't touch it, you're going to accumulate tech debt. Now imagine if you have dozens, hundreds, sometimes of engineers shipping code, day in day out on this code base. Now, complexity levels go through the roof. So you know, to go back to your original question. And to summarize, I think the way you convince the company of dealing with a piece of debt is by taking the time to create a build a real business case for why it should do so.

John

Do you have an example use case it just like off the top of your head that you might kind of just throw out there for starters.

Alexandre

An example use case you're talking about a piece of debt? Are you talking about, like maybe

John

Just one story to kind of help give us like that first example that we can maybe take away to our own work to maybe get creative with and how we describe and get buy in from a stakeholder?

Alexandre

Yeah, that's an excellent question. And then I'll give you an example. For step size, actually, because we use step size on step size. You know, one of the big components of our product is the integrations that we've built with GitHub, JIRA, that code editors, etc. And one of the sort of pieces of debt that we have in the code base has to do with which version of the GitHub API we were using to build a bot that allows you to report tech debt directly from your code review. And when we were using the old version, they moved on to the newer graph qL version, if I'm not mistaken, which I didn't build myself, right. So I'm gonna, I'm gonna keep it fairly high level. And we had to decide whether we were just gonna, you know, keep going with the old one, or build with the new one. And when we looked at our roadmap,

John

sorry, I keep interrupting you. But when you're seeing this transition, you're not only going from it sounds like you're going from rest to graph traditional rest. Yeah, JSON APIs to graph QL. This is not a cheap transition.

Alexandre

No, no, no, no, you know, for us, it is cheap, because we're small. But you know, we have sort of four or five people shipping code, and the code base is still relatively small. But imagine, you know, making the case and then at Priceline at the company where you work, for example, this is a massive endeavor, you know, and so we had to decide whether we wanted to keep going with rest, or whether we wanted to wanted to move to graph QL. And after looking at all of the modifications, the improvements, the features that we wanted to ship on our GitHub integration over the next month, you know, we didn't need to look fine to the future, to decide that, you know, a, there was some features that we would have a really hard time to build, if we went with graph QL. B, some features were just not possible with the old REST API. Right. So some things we wouldn't have been able to ship, we had been tracking the amount of time that we were losing, we thought because of the fact that we were using rest instead of the graph qL API, it was, you know, a handful of engineering hours. But for us, it adds up over the course of Sprint's and we had a few bugs in the way that the integration was working, that we think we thought we would eliminate quite easily if we dealt with the root cause and moved over to graph QL. So we made the move. But you know, I'm talking about this is a fairly simple example, for a fairly small company, you know, some of our customers, I won't quote any names, but have the same idea, right, where you rely on third party integrations to provide the service that you provide. And you get much bigger so you build integration on integration. And then you realize that you need some abstraction layer to sort of handle these integrations and to be able to answer them and modify them and do so properly across several engineering teams, not just one, like ours, and not just for a bunch of people that are set together around the same table. And to do that you need to go through a very serious process that you actually you told me about you guys have a very good version of it. At Priceline. He told me about your technical steering committee, where you take the time to create a proposal explaining explaining the business case for doing this. You say in the past, we have shipped these features that we estimated would take X amount of time they took y amount of time, which is 50% more than we expected. I staff engineer who knows the codebase and has taken the time to look at it. Think that If we built it with this abstraction layer, we would avoid wasting this amount of time. And looking at our roadmap, we're going to ship three new integrations this quarter, this is how much time we're going to save this is how much money it adds up. Because we're talking about three teams of engineers. Let's do it now, as opposed to let it bite us in the butt and have to come back to it later, when By the way, the more time you wait, the bigger the problem will be. Yeah. So you have to factor all of these things in to be able to convince the powers that be that you should invest resources into dealing with this stuff.

Alex Bachuk

How do you even deal with side effects of these big, let's say technical depth or migrations, transformations, let's say let's just use the same example as from going from grass to GraphQL, there's obviously going to be some things that will come up technical debt related, like you'll have to breed some dependencies, you'll have to do some refactoring. So obviously, that will come up but it's unknown until you actually do it, and you launch it or you beta launch. And then things will come up. How do you account for those side effects in advance where maybe you don't?

Alexandre

Yeah, so I think that there are many, many strategies about how you would refactor, say, a code base to move from a monolith to microservices, or whatever it is you're trying to do, or back again, or back again. Yeah. And there, there are people who are much more qualified than I. So you know, get into the detail of that. But what I would say is, I would compare the consequences of not doing it with the risk that you incur, doing this stuff, you know, let's pick the example of the monolith. And micro services. not actually a general example, the way a lot of older companies deal with tech debt is they just do a massive rebuild every three to five years. Yeah. And that's what will happen, you will take six months to a year too much more, to rebuild the whole thing. And I've spoken to companies who it's like, it's a bit, I laugh, but it's not funny. They, they were building some of that stuff, or maybe an older stack, you know, using some Oracle DB or whatever, and the poor CTO is telling me, you don't know, the worst is I'm locked in to a contract to be using Oracle DB for the next like, five years, you know, and then, you know, you stack dependency on dependency like this, and I have another contract, and it's staggered, and another contract is staggered. So even if I wanted to, I can't get out of this stuff all in one go. So I need to somehow devise a strategy where I can extract myself from all these commitments, and it's a lot harder than I don't know, refactoring some modern JavaScript stack. So anyway, I'm just, you know, doing a bit of fear mongering here, sort of compare the negative consequences and the risk of not doing it versus the risks you incur with doing it today. And most of the time, it's worth doing it incrementally, you know, starting today, rather than in one big go in five years. Yeah, yeah. I think you gave me another thought, which I lost. And I'm gonna give myself a second.

Alex Bachuk

Yeah, I was gonna, I was gonna say that, with these big projects, and bigger technical debt projects, and going back to certain technical steering committee, when you make a business case, when you have, let's say, a legitimate reason to address technical debt and have some investment, let's say, Take three months to do it. And countering those side effects may make things worse, because you're asking for three months, you're asking for, like, it's gonna take this much time. And instead, it can turn into a year project, or it will open up a can of worms that nobody wants to see.

Alexandre

Yeah, actually, you reminded me of what I was going to say, I think the way you deal with that risk is by applying the Agile methodology, the same way you would ship a product, you know, you don't go and ship the 20 of the thing, you start with the zero, you do the MVP, do proof of concept, you put it in front of customers, you see what happens, and so on, you iterate your way through it. So that's how I would approach any big technical debt project. I understand that. It's not always as clear cut, for example, what we just spoke about, you know, the CTO is locked into 15 different vendors with staggered contracts, kind of has to do it in one go or not at all. That's complex. I don't know how to I don't have a simple silver bullet for this one.

John

I mean, I don't know how how you could It's, um, you know, the decisions we make kind of what's actually this is kind of leads us into So, Alexandra, you wrote a really great article on what is technical debt Really? How long ago did you write that piece?

Alexandre

That was one of the first pieces that I wrote to try to clarify my thoughts on the topic, and I think you'll see That what I'm going to tell you about now is slightly different. You'll see the germs and the idea but slightly different.

John

Yeah. Okay, I can have empathy for where that why this piece is so important because of how your product is strategically positioned. And I think it's really important. And when I was reading it, I felt like that you were trying to get a common ground to have a conversation about technical debt. And so and part of it was you took a crack at defining it. And Alex and I have a lot of respect for who you're inspired from. Uncle Bob, I think was in there. Ward Cunningham. is Martin

Fowler, as well as another big one foreign

Martin Fowler. Yeah, absolutely. So I wanted to just kind of I took some notes. And I think for this for the next little little bit together, I'd like to ask you maybe some probing questions into your thinking, and maybe you your your mind has changed a bit. Now. So I'd like to actually start with how you've described technical debt, you describe it as code as written yesterday, that is a burden today, this is not the same as all code is a burden. Yeah, describe the difference?

Yeah, that's the bit where I changed my mind a little bit. So if I were to rewrite this article, here's the definition that I would give you, I would say the technical debt is code that you've decided is a liability. So the definition you had in there, I mentioned in the article, I think, was a more convoluted way of trying to say the same thing. So I'll explain what I mean by code that you've decided as a liability. technical debt is inevitable, as we said, It's the result of entropy in your codebase, Martin Fowler talks about how it can take up to a year of working on a project for you to be able to identify the ideal design for what it is you're trying to build. And that's just due to the fact that, you know, when you build a thing, you do so based on your understanding of the problem at hand, and then you go off, and you know, you speak to customers, people use your product, things evolve, things change. And so the business context changes, and boom, all of a sudden, the code that you wrote is no longer appropriate, not because the codes changed, but because your understanding of the problem, and the situation has changed, right. And so that's the moment at which you decide that this code is now a liability. It may be perfect, but you know what, we started this company assuming that all our customers would be in the UK, and now we're dealing with multinational companies have to deal with 15 different currencies. And our system is not built for that. Yeah. Well, the codes a day ago was fine. But now you've decided it's not. So now it's tech debt. And I am really spent a lot of time to try to simplify it to this point, because, you know, I think there's a lot of noise in the conversations we have about technical debt, people love to talk about process debt designed debt code debt, this debt, that debt, at the end of the day, document that I don't think it matters, you know, if you've decided it's a liability, it is now tech debt. And you should figure out what you want to do with it. either leave it to monitor it or deal with it for good reasons that move the business forward.

Now, what I found something actually just reemerged into my into my head. I wanted to I didn't want to interrupt again. But some companies, there's I think there's a curious connection between companies that rewrite things every three to five years. And the average engineers duration in a company.

Alexandre

Yeah, yeah, exactly. Yeah, for sure.

John

Like, we have to write things every three years because those engineers left and we need to rewrite the things that they wrote. Yeah.

Alex Bachuk

Are you saying that engineers like new shiny thing? Just like to rewrite things? Like new shiny things? Okay,

Alexandre

I agree. I agree. Yeah. But you know, they want to build and ship stuff. So

John

again, well, here's, here's the connection here, too. So Ward Cunningham, actually, I think was Martin Fowler's inspiration. From it actually describes it, the way that you did is tech debt is an alignment between how well the software or code reflects their current understanding of domain and features or represents, and that people should do their best to represent the features in code based on how they understand these things today, in a way that would allow for it to be refactored later, based on the learnings they may have had. Yeah, right. Yeah,

it's such a good description. I mean, the the analogy, you know, between technical debt and financial debt is one of the best ones I've ever seen about anything. Because when you think about it, you can use technical debt as leverage, just like you would financial debt, right? Like, we are going to make this we're going to take this loan to do this thing faster, better, whatever it is, and we know that over time, we're going to have to pay the principal back there will be interest, you know, there are consequences to this decision, and you need to deal with it. And the same goes with software. So there's often a very clear distinction in the Companies that are pre product market fit and post product market fit deal with technical debt. When you pre product market fit the whole thing's an experiment, right? You have some assumption and intuition, a hypothesis about what it is you need to do for the customer, you find the minimal version of that, you ship it, you learn, you change, off you go, oftentimes, because you don't have any real customers who are using your product all day, every day and paying for it. The way you deal with your debt is you just throw the code away. And that's fine. You know, that's the best way to deal with that. But then you get to a stage where you have customers who rely on your software, you have a platform that you need to maintain, you can't afford to just switch it all off and Bin it and start again, you have to work with what you've got. And that's when you start, you know, having to pay back the debt in a slightly different way than just tossing the whole thing away. Right. So yeah, I love the analogy. It works on so many levels. So we can't declare bankruptcy every time. Exactly. Exactly like that. Exactly. Yeah.

Alex Bachuk

So you Okay,

Alexandre

okay, God, so 11, you can only do

Alex Bachuk

that. That's what we like to do. Right? every couple years. So what is what are good examples of technical debt? Right? So it's all kind of vague at this point. Like, it's, it's the code that we write yesterday. Now, it's technical debt today? What are the like specific examples of technical debt that we can? We can name?

Alexandre

Yeah, the way I like to think about it is in terms of what it impacts at the company, right? So like I said, earlier, productivity, quality or morale, right? You can feel utterly miserable working with this code, because it has ossified and someone who wrote it did not document it, the quality of the code is terrible, the complexity levels are very high. Therefore, it's tech that like, and you can imagine so many examples of this stuff. It's a fairly classic one.

Alex Bachuk

So when coded, I don't understand, as an engineer, it's hard for me to read to to, to understand its technical debt.

Alexandre

Yeah. But I would be careful with this one. Because often, people have a hard time understanding code that someone else wrote, it doesn't mean that it's not appropriate. So I'd really focus on whether this this code is following whatever standards we've agreed to follow at the company. If we decided that we would add helpful comments, does it have helpful comments, if we decided we'd document it? Is it documented or this kind of stuff, right? That's one category in which you can imagine multiple examples of tech debt and, you know, tools like your code quality tools, a great way to find code that is rated f because it's highly complex, and it doesn't have comments, and it's to fair enough, then you've got types of technical debt that relate more to the way your system is designed, and architectures. You know, we spoke earlier about the example of a company that has a lot of third party integrations, it's kind of their business, it's part of their product. And if they don't reject the way they build these things, it's gonna slow them down a lot. So it will impact productivity, you know, or maybe it will cause bugs, etc, etc, etc. So, you know, earlier, john, you were saying that the definition of debt we're working with is not that all code is a burden, or code is debt. Right? That is true, because there's some nuance, but I think that all code has the potential of becoming debt. So you were asking for examples. I think the examples are very company specific, because what matters is whether they're in the way of your company objectives. If you say we care about shipping fast, then the debt is what gets in the way of shipping fast. If you care, we need supreme reliability, and something called outages. That's the debt.

John

I just want to take a moment to just put an exclamation point on something that I think is could lead to very powerful conversations within a team is making the argument of how do you put described tech that as something that is preventing you from doing things more frequently, kind of rests that in your mind as you're going into your code base tomorrow, or next week. And you're kind of like arm wrestling with something that feels complicated to like, I think we would encourage you to have that conversation with your stakeholders and say, say it specifically this is preventing me from getting something done. Then point at it and describe it like in the moment and just and, and have that conversation more frequently. Because I think a lot of times as engineers, like we suffer in silence, something that my, my yoga instructor would tell me to do. Yeah. Suffer silently. And if we don't describe these things, or at least, like present opportunities to our stakeholders, That I think is probably just if we're struggling with getting prioritization or describing the business add value, are there i think is kind of just like a good spot.

Alexandre

I totally agree. And, you know,

I think that's where the problem is. It's in the way we talk about tech debts and the way we communicate tech debt, because if you, as a technologist go to a non technical person and say, this is the very technical reason why I don't like this stuff. It's they're never going to understand it. Fair enough. Yeah, who cares? Like, it doesn't matter.

John

I don't care how you feel.

Alexandre

Yeah, it doesn't matter. Also, it doesn't mean anything to me, right? And if if you go and you say, look, there are technical reasons why I care about this stuff. But really, it's getting in the way of this business goal that we've decided we will all here today to accomplish. Of course, everyone's going to rally around it. Because you know, people want to do good work, and they want to work together and they'll cooperate, right? Yeah. That's where communication breaks down. Typically, when I you know, I spend a lot of time speaking to engineers, but also product people. And there's this sort of gap in between the two where they just don't get each other. And if they just managed to speak the same business lingo and go towards that same common denominator, which is what are we actually trying to do as a business? Then you're good, you'll make the right moves.

Alex Bachuk

Okay, so we talked about the things that exist today, like its impacts productivity and morale. Like I don't understand the code that makes me less productive. I cannot ship things as fast as I can. What about risks, things that don't exist now. But there is a potential or high risk that we know that will happen eventually, if we address?

Alexandre

Yeah, that's an interesting one, because it's kind of like doctors and lawyers, if they do their jobs properly, you never really know the value they've brought to the table, right? If I maintain my codebase, properly, things will not go south. So I was speaking to a guy yesterday, who made a point every two weeks to put in a short deck in plain English, the incidents that they thought they had avoided because of maintenance work that had done in the past. And he would share this with his boss, the engineering manager. And the way he did that was, he's in a in the data engineering team for a very, very big company. And they have very good tooling, I think they use data dog as their APM. And they could, they could tell all of the issues that they were piling up in the past. And then they fixed it. And they said, This is what we avoided in the future. And I say this, because with this habit, they sort of developed an intuition for what the risk is for x, y, Zed piece of debt not being dealt with. And they they talk about it with that to the project owner and their product managers, they told them, this is what I anticipate might happen if we don't deal with that. We care about reliability, I think it's putting us at risk of an outage for these reasons. Give me this amount of time, and I'll try to fix this thing. But I'm glad you asked the question, because effectively, the reason that we want people to measure the impact that a piece of debt has had on their work right now is not just so they can use these totals to make decisions, but so they can extrapolate into the future, right? We keep using this easy example of, we touch this code this many times with these features, this is how much bad stuff happened. In the future, we will touch this code, this comparable amount of time, I predict this much extra bad stuff will happen that you need both sides of that that story.

John

So I'd like to get a little bit back to how we're describing tech debt as somewhat of an alignment between the domain it's working in and how it's represented by the people creating it. So going through my notes here. So whenever I see a new team form up around a system that was built by someone else, so a team comes in, they're taking over a piece of software, this hat change management happens frequently. One of the first things we usually hear is after these new the new team gets a chance to look at the system is this makes no sense at all, we have to completely rebuild it. And it very well could have already been operated maintained by a team of five, six plus, plus other individuals. Would you say that the behavior might not be a true representation of the code, or a better reflection on how the people involved are expected to understand the domain and how they're working in it, and might have different ideas on how they would organize the code to meet the requirements of the domain is how this is so so like raising another way, right? Like you have a whole new group of people being introduced to a problem domain, maybe for the first time coming into like taking over a piece of software that was defined by other folks that are already been immersed in this domain. And now maybe there's you know, they just have a different way of solving the same problems.

Alexandre

Yeah, I really like what you described here, because I think it illustrates the point we made earlier is that the code we write is based on our understanding of the problem at hand. And if someone else comes along with a different understanding of the problem, of course, it's gonna seem inappropriate, right?

John

And if there's a, there's a mismatch, right? There's a mismatch. Yeah.

Alexandre

Yeah. And then you take the time to get on the same page, and you go, Hmm, okay, I get it, I see how it came to be, might not be how I would have built it. But you know what it works. And my goal is now to add this extra thing. I understand what they were doing. So I know how to add my extra thing here. Right? It makes sense. So yeah, I really like the way you describe this.

John

So when I study a piece of code, I try to read through how it is organized. First, to get a sense for how the originators thought about the domain, and the problems they were looking to solve. Most of the time, I find that at first, I might cringe or I might disagree. But as I come to terms with how a program is laid out, I begin to understand the parts that can be extended, and I start to develop like an appreciation for the decision making maybe like, there was a shortcut that they had to take for, for instance, or maybe like at the time, they didn't have access to certain types of resources that they do now. So it's easy to kind of judge those things based on hindsight, which sometimes isn't exactly fair. So is tech debt, a people problem or code problem?

Alexandre

Yeah. Okay. I love this question. Before I answer that one, I'll comment on what you said before. One of the most popular features that we built it step size is that when you report a piece of debt from your editor, we add a little little icon saying careful, someone reported some debt, and you can check it out. So then you understand the workaround that they might have been catering to, and the reason why this thing might look weird and how you get it. Right. So and now I understand why this feature is so popular. So thanks. Can you repeat that question? So you asking if take that as a people problem, or a code problem, a code problem?

John

So, because all of the definitions we go by is the code we create yesterday. Is that today? Yeah, right. Yeah. So but it's, we're really what we're depending on if we're going by, like, a human perspective on humans, or we're creating the code. And if it's our job to write code that represents the domain if we all agree that that's a good thing. And that change management is hard and leads to building more software in different shapes. Is technical debt. Like, is it the response? Is it is code really where the issue is? Or is it more of a people issue?

Alexandre

Yeah, that's a great question. I am. I think it's it's a bit of both. And I'll explain why Martin Fowler has I mean, one of my favorite pieces of his I forget what it's called, it might be, I think it's called the technical debt quadrant, you should go check it out. Yeah, in the technical debt quadrant, he explains how a piece of debt can be reckless or prudent, and how it can be taken on deliberately or inadvertently. And, you know, I'll give you an example of why I said, it can be about code, if you are reckless about the debt that you take on and you write poor quality code that isn't designed properly. Like this is technical debt that on the one hand, all about your code, because it's it's, you know, objectively bad, and on the other all about people, because you're the one writing code. Right? So we've got both here. And then you know, on the other As for why it's all about people as well, we can use the example of what we said of you know, you've got a piece of code, and someone else shows up and sees the problem differently, and therefore, it's potentially tech debt to them. Yeah. So I don't think we can distinguish either what I would say, though, is that there is a good kind of debt and a bad kind of debt. Right? Right, a former, which is reckless and inadvertent is bad, you know, no one should aspire to write code like this. And you know, we should avoid it. technical debt that is taken on prudently and deliberately is totally fine. And in fact, if we didn't use it for extra leverage, we'd probably be too slow. And we'd probably end up getting beat.

John

I agree with that. Yeah, there are sometimes it's appropriate to take a short cut cut a corner for the sake of meeting market demand. Exactly. Yeah.

Alexandre

Yeah. So. So yeah, I'd say both. But you know, the reason there's a gap in the market and why step size is the only solution of its kind is, I think, because people tend to forget about the people angle

John

was actually, I was actually just gonna say that. And that was something that I admired about step sizes. How much of the people are involved in the process? It's not just delegated away to some appliance that will just kind of do it for you stamp a score, like arbitrarily I mean, the gamification feels good. We like to think we're leading to better code. But I don't see how those tools help us make the code fit the domain, because those tools can never understand the domain.

Alexandre

Yeah, they never will. It's, again, they have their place. But I have, you know, stood in front of the report that we put together on some really top companies code base, looking at it with the chief architect, we had a great conversation about the metrics in there with the old product, right? And he just told me, okay, now what exactly do I do? I don't know. I guess, go speak to the teams who deal with this code that we've said as a hotspot. And here we are, it's all about the people.

John

Yeah. So if we're depending on people to describe tech debt, how do we know it is the code that needs to change instead of the people working on it?

Alexandre

Yeah. So going back to the previous point about reckless and inadvertent debt, I think you still need to have solid grounds in terms of the you know, the engineering processes that you work with the standards that you aspire to the way you train your people, the way you review your code, the, the levels of quality that you aspire to. This is just table stakes, like everyone should do this stuff.

John

Well, in the in the world of agile, though, it's a little tough, because, you know, like a lot of teams and engineers, I know, and feel free to disagree with me here. We're not encouraged to look at the big picture. Yeah, we're encouraged to look at these like very tiny increments. And what I find sometimes in my practice, and when Alex and I are working with folks is we're always encouraging people to talk about the why but, it seems like agile has been so kind of like process driven, it's become less like organic and more, here's like a means of control that is robbed and completely dehydrated. That story. So it seems like our agile practice, and I would wager in most cases, robs engineers of being able to fully understand the domain in a way that can be accurately reflected in the code. And instead, we end up with like, these kind of one off patches, on functions that kind of just don't really make sense. Things that, you know, and, and maybe like, maybe we're actually with our agile practice, we're robbing the opportunity of, of even reducing the opportunity for tech debt.

Alexandre

Yeah, I am. I like that you brought this up? I think, again, just yesterday, I had a lot of calls yesterday, I was talking to someone who, who told me that, in their opinion, agile has been misinterpreted. Yeah. So think just about going fast.

John

It's is kind of an unforunate name isn't it?

Alexandre

Yeah, yeah, it is. It really is. Like, you know, people think that because it's called like that, it means that you can just, you know, make a 180 move on a whim and things will be fine. Yeah. Or that, you know, everything that you're ever going to do is going to be quick. And they'll always be some short solution. That's just not the case, especially with the kind of stuff that we build. tonight. I'm glad you brought this up. And I mean, I, I suppose that's the challenge is to be able to keep the short term and the long term in your mind. At the same time, you know, that's like the contradiction that we deal with. And, you know, I often get reminded about how important it is to remind everyone is doing anything at the company about why they're doing it, you know, like, you're not just building this thing to fix this patch, or this bug, you're building this thing, because we care about retention, the customer uses the product in that way. And at the moment, they can't do it because of this. And you know what, that's our quickest solution. But in the long term, this is what we want to do about it. It's just people are a lot more invested and motivated as well, when you manage to draw that line between what they're doing and what's actually happening for the company. So again, we're back back to this. I think it's just good management practice, isn't it?

John

I mean, what could a manager do to help out? Like, if you're a technical manager, and you're leading a team, and you know, you're running? I prefer Scrum. Because Scrum, I think is, is more team oriented. It removes like, it's, it says that we are practicing something together, and we're trying to make a move. And it's a rugby term, right? Yeah, I'll be the ball can move either way. Yeah, the ball can move against you in some way. And you got to think critically, like, Okay, what do we do now? What's the next thing that we should do? So lost my place here a little bit?

Alexandre

You were asking what a manager can do? Yeah, I know exactly what to tell you about

John

that. Oh, good. Because

Alex Bachuk

that's the answer. We want to hear

Alexandre

Some fairly simple things that I think will be really impactful. Number one, when you think about it, typically engineers get rewarded and see that careers progress if they ship features quickly, and well. Yeah, yeah. On Fridays, you do the demos, and everyone shares because you ship this new thing, and it's amazing. Do the same thing for the maintenance work. You know, like remember that this big reef job that saved a lot of people, a lot of anguish, and the company a lot of time or money or whatever it is, should be celebrated as well. So maybe it Friday demos, let people demo their big refactoring or this new abstraction layer on top of the integration system that you have. And let them explain how much of a big deal it is for everyone, and let their colleagues pat them on the back and tell them I'm so happy you did that, because I was not looking forward to working on this thing. And the next quarter, you know, and actually reward them in how you promote people, I suppose. The next thing is, you really need to make room for conversations about technical debt and maintenance work in all of your usual Scrum or sprint to agile ceremonies. When comes the time for planning, if you're the PM, you might not have the answer. But ask, Hey, what technical debt would put this feature at risk that we want to ship here? And, you know, go speak to the team leader who takes care of that stuff, you'll you'll find out what will put your staff at risk as well, you'll start having the right conversations, if they start geeking out on the technological aspect of this thing. Ask them, like, Hey, we have these okrs for the quarter, can you please help me understand how fixing this thing or changing this thing will help us move the needle on this stuff, you know, and like this, you'll build the right habits. You know, I know, john that you told me about the ideal template for a JIRA issue that you would like people to fill out when they describe a piece of debt that they find in the codebase. That's another thing that a manager can do, you know, like help help implement these, these best practices. And I think it's part of how you train your people, you know, they'll pick up the right habits like that. And before you know it, your engineers at sprint planning will go, Hey, this feature we you know, scoped it out as a seven or whatever. But here's the risk, they'll put this metric at risk. And we should do this about that. And I have an MVP in mind. And over time, maybe we can iterate towards this, this bigger version of the thing later, you get what I'm going with this?

John

Yeah, I like I think there's an opportunity for for technical leaders to help their teams along with building the narratives that will have the impact, a lot of times, we get so used to just talking about the thing, like, let's say it's a car, like, hey, there's a car over there, this car, you can you can get in it, you can steer the wheel, and you can push the gas pedal, pedal and motion will emerge what will happen every once in a while, you have to put fuel in it to keep moving. Instead, though, like the manager, or the leader can say like, well, this is going to help you get from where you are right now. To to the other side of the country, if you really wanted to, yeah, this is like an opportunity you have if you actually have this. Yeah, right. And I think we can bring that language or help people around us in the data and the other way around, too, right? Because if we're so used to talking about the engine are so used to talking about the parts of the engine, get listened to the words that our stakeholders are using, bring those into how we describe our work, and that can help kind of loosen up the conversation a little bit.

Alexandre

I totally agree. It's not an engine, it's not a car. It's freedom. Yeah, that's a lot more compelling. Last year, we spoke about that problem of sort of speaking the same language between the technology side of things and the business side of things. The managers in the middle can help translate and sort of train middle management the same, to speak the same language.

Alex Bachuk

Also encourage people to think about opportunities with technical debt, not only what can we should address and prioritize and existing technical debt, but think ahead and think of the long term impact. How can I refactor my code? How can I invest in technical debt right now and prioritize it in the way that I'm going to have electric car and if you'd ever and not think about the the engine as it is right now?

Alexandre

Yeah, you know, I am. I always found it so cool. how, you know, Elon Musk make made sure that you could deploy updates to Tesla vehicles, before there was any kind of self driving capability in the stuff, you know, it's this this kind of move, you know, know where you're headed. And it'll make a difference.

Alex Bachuk

Yeah, you're helping your product managers, you're helping your business stakeholders, with the future innovation with future business opportunities, by addressing technical debt point and prioritizing technical debt and the way that it's more flexible and gives them more leverage in the future.

Alexandre

Yeah, that's exactly right.

John

So a couple of other things I just I don't mean to pivot too much with you guys. But so looking through kind of what's what's were was presented by step size. There's a quote on your website. So Stripe says engineers spend 33% of their time dealing with technical debt. What does that say to you?

Alexandre

Yeah, first time I saw this, I went, Wow, this is a lot of time. That's like a third of anything they do. I don't know the methodology that they applied, I think they basically did a survey where they asked engineers, where do you spend your time. And they would say things like, this amount of time debugging this amount of time refactoring this amount of time on maintenance. And then they lumped it into this this term that we use technical debt, to describe all of this work. So I mean, what it says to me is that it's really important, yeah, to figure out how we're going to handle it, you know, and there's another quote that's not on our website. But I really like, I'll tell you that story. During the pandemic, a lot of companies had all of their commercial activities completely frozen, right? And so the engineers had to figure out what they were going to do. And lo and behold, they start looking at how they were going to maintain their codebase. And Gartner got a lot of requests from leadership at these companies, who were asking for help, like, how should we maintain our codebase? How should we deal with technical debt, and they took the opportunity to do their own little study. And again, I don't know the methodology, but they concluded that the companies that they spoke to had some strategy to deal with tech debt, not even a good one, just a strategy ended up shipping 50% faster than the ones who didn't. And it sounds a bit nuts. But think about all the times that we scheduled a thing for a sprint, and then it took a month. Yeah. And imagine this at the scale of a company. And imagine this on a global scale. Because that's how fast stripe went with their research. I think they said, you know, the loss in engineering, productivity is costing the world $85 billion a year or something like that. That's mad.

John

I have I got a man. So I appreciate the metric. Yeah, but we have the luxury, we have a luxury to stand on the shoulders of giants. Oh, yeah. Right. We have technology, we have software, costing us anything. I mean, I don't I don't know if that's an actual. I have a hard time swallowing that as real debt or just being like, you know, Oh, geez, because I have software, I have these money problems.

Alex Bachuk

Like, it's like the movie industry is talking about piracy. It's like you just like you pretend and all these people would buy the movies instead of downloading them. We would just never happen.

Alexandre

I know. You mean, I think I think I'm doing doing them. I'm not doing them justice, the way they framed it was more of a, you know, this is the opportunity, right? This is what we stand to gain. If we do better with these things. Generally speaking, these large numbers, they just make me think, Wow, this sounds like a big problem. I don't really mind if it's 80 billion or two or 500. That's just it's a big problem. And I'll tell you what, the thing that speaks to me is not the fact that it's a big, big number is that it makes people miserable. You know, engineers don't want to work on this stuff, and it sucks and you want to build, you know, you want to build your product, you want to show your stuff and you can't do it.

John

Is that true? Is that true, though? I mean? Okay, so here's, here's my take on that. 33% is based on the definitions, we should be spending time reshaping the code to meet the new demand. If we're not doing that, well. So what would you expect?

Alexandre

Yeah, yeah, no, I agree with you in the sense that the goal we're striving towards is not zero technical debt. Right? This business does not exist, right? Because it's an impossible goal, you can't do it. What we're striving towards is, you know, a bit of structure in all the mayhem so that we're not so lost and overwhelmed all the time about it, you know, that's all you can ask for. It's just dealing with your tech debts as a fact of software development life.

John

Well, there's, there's also I think, we nomina, I would wrote myself and my mindset into this. And because I am also a contributor to this, to this to the style of thinking from time is the term weak signal detection, I cannot immediately recognize what's in front of me. So I will immediately discard it and say it without actually digging into it and evaluating it based on its merits. For instance, I've worked on software. I've worked with some folks, I help them out with some old AngularJS applications. When I say that to some folks, they cringe like, Oh, geez, you Angular, Angular JS, like, Oh, wow. Like, I don't want to have to deal with that. But I'm looking at as an opportunity, you know, what's there I'm trying to understand how it's described. And I'm working with the business to help them understand like, Where do you want to go with this? Here's what you stand to benefit if you get something, you know, yeah, nice. You know, really, there's, there's, in my opinion, there's no real excuse. Other than we just don't like it enough.

Alexandre

Yeah, yeah, and I mean, what you said to his, I think, related to what you were saying earlier about connecting it to the why, you know, I'm not I'm not here to work on anger, I'm here to help this business move forward. And I love the stuff they do. And, you know, it'll be a good thing for the world. And I can, I can empathize with what you're saying about Angular, because tech debt is a bit of a dirty word to some people, you know, they hear it that I don't want to deal with it, and what you're building a company to help people with tech debt, and I just tell them is a dirty job, someone's gonna do it. But actually, I don't think it's a dirty job. It's just part of building software, it's so cool to go deep into that complexity. And I managed to simplify it into a few systems that you can use to make sense of all this mess.

John

Absolutely. So the next thing that I think is really powerful, and I want to make sure we we touch on is roadmapping and planning. So I'm associating tech that with your roadmap, on your website, you say that you can address tech debt blocking a roadmap? How do you see teams achieve that level of clarity using tools like StepSize?

Alexandre

Yes. So what I would say is that sort of the general principle applies, regardless of how you would build your roadmap, what you want to do is you want to clear important roadblocks before you send the whole team down the motorway at full speed, I'll just run with this analogy. It's sort of it's very simple, but often overlooked, because of what we spoke about my health tech debt is so overwhelming, and we don't have a system to deal with it to make these decisions. So the question always becomes, do we clear the road? Or do we take a detour to avoid that obstacle that we just spotted, and the way you can think about it is if you plan on driving down that road, often, or if you use it to transport some vital cargo, then by all means clear it. But if you have enough fuel to take the detour a few times, and the time you waste doing that doesn't compare to the magnitude of the job required to clear the road, then don't clear it. So effectively, what you want to do is you want to find the overlap between your roadmap, the code, it's going to touch and the tech that lives in that code, right. Let me let me say this again, because I think I might have messed it up. There's this Venn diagram between, there's your whole code base, and there's a chunk of it that relates to your roadmap, the stuff that you're going to execute on for the next month, this is the stuff that you want to focus on. And within there, you want to find the things that cost the business the most or impact the KPIs that really mattered to you, in the most negative way. And then you clear these roadblocks.

John

Yeah.

Right. Okay. And where we're stepsize kind of like helps with the roadmap planning and pull it all together, I think you helped connect it for me is because the team if you're if they're subscribed to stepsize, and they're actively working on cataloging inventorying, things that they understand or as recognized is that over time, you can use that as inputs into your planning and your roadmap to say, hey, look, I know in this quarter, we plan on doing this, when I pull up this report, I can see that engineers are having a lot of problems in this area. I think we should set up some time in advance to clear the road to kind of steal your metaphor.

Alexandre

Yeah, that's exactly right. I'll tell you exactly how it goes down. We're planning we say we have these features. Hey, mister missus, engineer, which parts of the codebase will it touch the integration system and the data models cool, open step size, have a look, we organize the data based on the domains in your codebase. You can see integrations vs data models, ooh, there's a lot more debt and integrations open it up. We care about the speed at which we'll ship this filter based on the tech debt that's causing us to waste the most time Have a look at it. This is the top rank. This is what you know, the person who documented this piece of debt has to say about it. This is the business case for it. Cool, let's break it down into issues that we will deal with before we ship that feature. It's part of the sprint and off we go. Right. That's how you make the decision. Awesome.

John

And I'd like to just peek into measurement as we're getting kind of wrapping up here. And so how do you so working with teams? What are like the kind of the big levers or characters? How would How do you help teams understand how to characterize their problems? Or do you provide a language for them to describe what they're seeing or what they're experiencing? For the sake of it sounds like for if you're going to report on any of it, you have to at least have some kind of tagging mechanism or we'll have something commonly so you don't have people just creating randomness all over the place. Yeah, it has to be some kind of structure.

Alexandre

Yeah, and it's really important. So one of the first things we do when we start working with a companies we help them organize the data hierarchy in their accounts. And it starts with the way in which you would split your codebase the domains in your codebase you know, for us integrations data models, front end back end or this feature that feature some people have, you know, a feature for each domain in their codebase. And that's, that's the language they use to talk about they their code, they go, Hey, the authentication code, the payments code, we set this up. This is really important, because these are the buckets in which you put take that right. So if you come across that that relates to authentication, you put it in that bucket. Now, another thing that we relate to them is, people are really interested in hearing the process that we recommend they use to deal with tech debt. And maybe Actually, I'll tell you about this one quickly. I've simplified it as well. Regardless of it doesn't matter what type of tech debt you're dealing with. I think what matters is whether it's a small, medium, or large piece of debt, and I'll explain what they are. A small piece of debt is a thing that you can fix right then and there. To quote, Uncle Bob, you apply the the boy scout rule, right, you leave the camp better than you found it. And if you have the right engineering culture in place, engineers don't need anyone's approval to do that. They just see it, they refactor it off, they go great, medium pieces of debt is, I'd say a piece of debt that takes about a sprint, like whether it can be fixed within a sprint, essentially. And the way you deal with these is you have them go through your usual sprint Scrum, agile ceremonies, you treat it with the same sort of care that you would treat a feature feature work that you're going to do, right, you make the business case, you schedule it, off it goes. And then you've got the large pieces of debt, which I've categorized as anything that takes more than a sprint, which typically gets bubbled up to a technical steering committee, you know, kind of like what you described rights as engineering and product leadership that gets together once a quarter, once a month, whatever it is to decide whether these larger technical projects are worth doing. And again, they evaluate the business case for each and then they schedule it onto the roadmap, right? Why was I explaining all this, we were talking about the data hierarchy, right? You have your debt organized into the different domains in your code base, you then get to create what we call technical debt items that relate to these medium pieces of debt that you come across in the codebase, for which you make the business case, people as an engineers, individual contributors, who ship code, review code, etc, get to record all of the instances of these medium pieces of debt become across the codebase. Like, you know, here's us using the REST API, when we should be using graph qL, logging into step size, you know, I traced a bug down to this part of the code, and I spent three hours trying to understand it, that's the impact that it's had on the company, log it with it. And over time, what you're able to do if you track this data is to tell this is how much the debt in the code relating to the integrations code has cost us. And you get to bundle these medium pieces of debt into what we call proposals, the large pieces of debt that you would present at your technical steering committee. So you've certainly not bubbled up from the instances of that the small units of debt to these medium pieces of debt, where the business case, read the data to support it, then you bundle them into a bigger project. That's often the case, you know, we need to build this abstraction layer for how we do integrations. And again, this data that you've tracked bubbles up and helps you make the business case. So that data hierarchy is really important to help people make sense of all the data that they're lobbing into the tool, you know, without it, it'd be really, it'd be a mess,

John

absolutely, like, yeah,

Alex Bachuk

like, how do you organize it, the target was specific labels. So you have to like organize it by epic, or by project or by specific issue.

Alexandre

So typically, companies have a step size account where they have all of their debts for their codebase. In that there are tech debt groups, which represents the domains in your code base of the buckets in which you will put your tech debt. And in these groups, there are items and to these items are linked reports, which represent the instances of that debt. But really, a simple way to think about it is a tagging system is just a way to tag the data that you put in there. And you know, some data points are linked to others and they build into bigger ones, it's, we're going to change the way it's designed. So the terminology I'm using doesn't really matter. What matters is that you tag it with it's in this part of the code base, it relates to this piece of debt, it's called this much problems to the business. And then you filter the data based on on these on these tags.

Alex Bachuk

So you end up with like authentication, technical debt, or GraphQL technical debt like these bigger buckets.

Alexandre

Exactly. And then someone goes, we have to do this big technical initiative that involves this and that piece of debt in the integration system and the data models and here's a proposal to go with it and bundled up, this is how much it costs the business and blah, blah blah.

John

You know, This is like, you know what I really love. It's not often that I hear of a workflow that gives that encourages the bottom up influence that we so want most of the time, at least, Alex and I try to push for that frequently with the teams we work with. And this sounds like I really appreciate because as a manager, you can't really get a holistic sense of normally have a language to look at what's happening under the covers, because you're always dealing with an abstraction. But if you're able to see at a high level how, you know, going a bit deeper than just hearing what people are saying, and able to look at how they're reporting on what's happening in their world is kind of an interesting opportunity.

Alexandre

Yeah, I think you need to be able to link these different layers of abstraction to be able to get an accurate picture at the top, if you will. And even because you constantly go from top to bottom, etc. And it's it's kind of hard to explain. But when you're talking about a project at a very high level, at some point, you go and you scope it down, and you break it down into its smallest components, and you've gone from top to bottom. And the reverse happens. Again, if you want to use the right language to talk about technical debts, you find an instance of it, it's not about the code, it's about the domain and how that domain relates to the business. So you need to be able to get up and down all the time. Otherwise, you just can't talk about it properly.

John

Alexander fantastic. It's been so awesome having you on. And thank you so much as we're wrapping up here. Maybe I'm curious what's next for step size? And you know, how can people get in touch with you? And what reason should they contact you?

Alexandre

Yeah. So thanks for having me on. The episode is really nice chat that really enjoyed it. They can find us on Twitter at StepsizeHQ, they can get in touch with me on twitter again at Alex Omeyer. That's o m e ye if you're wondering. And really, if you want to have a chat about technical debt, drop me a line because I like I said, I spend most of my time doing video calls these days with any engineer that will have me any product person that will have me anyone who's building software to hear about how they deal with tech debt, what's worked, what hasn't, because this is what allows me to write original content, it's what informs the way we pitch the product, it's what informs the way we build the product. So just drop us a line and check us out. And you know, in terms of what's next for stepsize, we're gonna keep building out the perfect product to help you deal with that tech debt. The roadmap is long. It'll take a while, but come check it out. And we offer free trials as well if you're interested in taking it for a spin.

John

Alexander. Thanks again so much for hanging out with us today. Alex, any closing thoughts?

Alex Bachuk

No. Thank you.

Alexandre

Thanks, guys.

John

Thanks for tuning in to the programmatically podcast. If you found this conversation interesting or helpful, we would appreciate your feedback. If you want even more content like what you just heard, check out pragmatic lead calm. If you have a story to tell, send an email to pragmatic lead@gmail.com and someone will be in touch. Thanks again.