Managing Your Tech Debt When Execs Need Features
Hayden Baillio
Right.
Hayden Baillio
Let's see.
Hayden Baillio
We are live and we're waiting on people here.
Kelvin Del Monte
Everyone, welcome, welcome.
Hayden Baillio
Yeah, I'm having a hard time seeing everybody. if you're in the chat, throw a hi.
Hayden Baillio
Throw a howdy, throw a hello.
Just don't throw something at me, okay?
Kelvin Del Monte
You
Happy Wednesday to everyone that's watching. Happy hump day.
Hayden Baillio
Yes. Yes.
Hayden Baillio
Well, well, well, here we are.
Hayden Baillio
Alright, well, I think we should get started.
Kelvin Del Monte
Alright? Okay.
Hayden Baillio
just going to make sure that that your front and center. Calvin to me to you and my friend center or are you friends in a right now?
Kelvin Del Monte
We're both equally front and center.
Hayden Baillio
Equally front and center. love that. I love that as we should be. Okay, perfect.
Well, well, well, here we are, y'all. Thank you for joining us for this awesome, awesome webinar that we're going to talk about managing your tech debt when execs need new features. I'm going to cut to the chase here. We only got 30 minutes, and so I'm going to introduce our speaker today. Ladies and gentlemen, he might possess both the smoothest voice in tech and the rare ability to explain technical debt.
without making executives cry. As a solutions architect at HeroDevs, he spent his career transforming legacy systems into cutting edge platforms and helping people solve their technical debt problem by making it disappear. I'm just kidding. But truly a man that absolutely understands the quicksand that is end of life software, where HeroDevs fits in in the life cycle management of said software.
And today he's going to show you how to ship features without your code base collapsing like that foldable table at your last family reunion, right? Please welcome the ASMR voice of technical debt management. Calvin Del Monte. Thanks for joining. Calvin take it away, man. It's all you, you know. It's all you.
Kelvin Del Monte
Thank you very much.
Kelvin Del Monte
Thank you very much. Thank you. Thank you, Hayden. All right. Well, I want to welcome everyone. Thank you for coming, for joining us. And to those that will be watching later, you know, since this meeting, since this webinar is being recorded, welcome on this beautiful Wednesday. Let's talk some technical debt. Before we get started, I would like to first introduce myself. I'm Kelvin Del Monte. I'm a Solutions Engineer here at Hero Devs. I've been a Software Engineer since 2008.
And during this time in my career, I've also had the opportunity to lead and manage several engineering teams. And the things that I will be talking about today are from my personal experience, right? I worked in all sorts of organizations, big ones, small ones, startups. And yeah, I've learned a lot through this process when it comes to technical debt. And I want to share with you. So first, I think we should begin with what is technical debt?
And, you know, this is what technical dead sort of feels like, right? I know this the popular representation, a meme out there, which I find super funny. Yeah.
Hayden Baillio
Kelvin, Kelvin, I'm sorry. I don't think that you're sharing your presentation yet. It's all good. Tech gremlins. This is our first one in the series.
Kelvin Del Monte
sorry, sorry. Thank you. Thank you for that. Yeah, let me actually. Yeah, no problem, no problem. So now you should be able to see it.
Hayden Baillio
There we go.
Kelvin Del Monte
Perfect. Yep. So, yeah, first we should... I was showing you this meme that you couldn't see earlier, but this is a super popular meme out there which sort of depicts what technical debt feels like. Although it feels like this, it...
It's not always like this, right? The house is not just absolutely in shambles like this and your boss is asking you if you can add a new window. How are you gonna add a window if the house is breaking down like this? But this is certainly what it feels like. We're gonna talk about that a little bit more in future slides. Before we actually get into what technical debt is, we should really talk about...
where technical debt who coined this term right who came up with it so is this gentleman right here mr ward cunningham he coined the the term technical debt back in 1992 i was three years old and he used this metaphor while he was working on a financial product nonetheless the financial product was called y cash and
He used this metaphor to explain to his boss what his team was going through as they kept building this software, this Ycash software. As development progressed, their understanding of the system and sort of their own opinions of the system that they were building and how they were building it was sort of evolving.
So, you know, they began building it one way. And then as time sort of went on, they found new paradigms, new patterns that they thought were more useful, that fit better with the type of work that they were doing. So it's almost like as they were moving forward in time, is the decisions which were optimal to them at that moment when they were, you know, when they were writing this code or setting up the application were optimal decisions, but
Kelvin Del Monte
you know, six months to the future, a year in the future, they've evolved as people, as engineers, and the software has evolved and they've evolved how they work together. Maybe they have new tooling. There's a ton of things that can happen during this time. And they found themselves in this situation where they were looking sort of in the code that they had built in the past.
And they had evolved. that code no longer looked up to standard with how they were building things now. So look at this. have a small team of people working on software. The code had not changed. They changed. Their opinions changed. And this sort of created this term of technical debt. So he explained it because as the team was sort of going back and interacting with this old code that they had written sometime in the past,
They experienced slowdowns when they were interacting with this code and Mr. Cunningham here, he explained it to his boss as this sort of feels as, you know, when you're paying interest on a loan. And this is where technical debt came from. Now, I want to take a moment to sort of reflect on this, right? What created the original, the OG technical debt? It was opinions.
and an evolution in understanding of the team, right? And this is important to think about because this, if you think about technical debt now, it hasn't changed. know, there's, you know, the term is so.
Powerful, the metaphor, so powerful that lots of people use it. 30 years later, 33 years later, people are using it. We're talking about it today. It's super powerful. And it has to do a lot of opinions. And as you know, opinions change. And everyone has one. So we have to make sure also to keep that in mind. Technical debt is based on opinion of what is, you know, what's the best approach to building software.
Kelvin Del Monte
So what causes technical debt? Technical debt is, as we talked about just now, is evolving understanding from team members. It can be any of these. As you learn more, your earlier choices don't make sense anymore or make less sense than the ones that you're making now. Short-term decisions. You're building a project and maybe you are in a crunch of time. You don't have enough time.
and you cannot think fully ahead or plan the project in a way that would help you see a little bit ahead or plan ahead. So you're making all these short-term decisions and they accumulate. And as you're making them, you're accumulating technical debt. You can also have poor architecture choices, which this could be due to inexperience or...
ineptitude sometimes, but these happens. very, very common when you have architecture choices and the entire app is sort of a big technical debt. You'd also have messy code here and there, just patterns that have come from different contributors that come in and out. Duplication, sometimes you have no tests. This also technical debt. And it creates technical debt. Team changes. Big, big.
factoring in creating technical debt. So you may have your team that you've been working, you know, team that has been working with you. Let's say you're the product owner or the stakeholder and you have a team of developers that has been working with you with no changes whatsoever for five years. They may not think there's any technical debt in their project.
But it just so happens that a few of the engineers leave, you bring on some other engineers that are coming from other environments. And to them, once again, it's very opinion based. To them, you have a ton of technical debt that they start calling out. This technical debt may be actual technical debt, or it may be their opinion. And it has no basis, right? No actual proof, which we'll talk a little bit about later as well.
Kelvin Del Monte
And of course, shifting requirements is a very common one. You have developers changing the same piece of code over and over again to augment a feature, change the feature a little bit without breaking their previous implementation. And it's happening very fast on the go. So as the iterations are happening on this piece of code, this also is tied to short-term decisions. A lot of decisions are made on the go.
on this particular feature or part of your source code, and this leads to technical debt. Technical debt is something natural that happens. I mean, we've already talked about this. It's an evolution, right? So as you're progressing forward, you're accumulating technical debt. There is absolutely no project on Earth that exists or will ever exist made by human or AI that will not have some sort of technical debt that sort of happens as you move forward.
So how does this affect you? So technical debt affects your project, your organization, your product in many ways. When it comes to security, you could have several vulnerabilities that you don't know about because they are submerged somewhere in this spaghetti code or this code that's not being maintained properly.
You also have this very one of the biggest complaints velocity issues. So actually the term was coined from a velocity problem, right? Mr. Cunningham was explained to his boss, hey, every time we interact with this old code, we slow down. So your team is your engineering team.
It has less speed because they have to interact with this old code that they are not really sure how to maintain or they think it's difficult to maintain. And this hurts, this ties in perfectly to the next point, which is it hurts developer morale, right? I've been in situations where you're in an environment where it seems like the entire application is tagged dead. And you're afraid to make a change because you could introduce a bug that brings the, know, cause of production issue loses the company money.
Kelvin Del Monte
is you don't want to be stuck in an environment like that because it's very stress inducing and you know honestly life is short you want to do some good work and not have to feel so much stress so it costs a lot of stress on the developers and it hurts their daily lives at work
So I have here a quote which is, business leaders should see tech debt as a delivery risk, not just an engineering concern. This is a part of how you get buy-in, and we're going to talk a little bit about that in future slides.
Hayden Baillio
well.
Hayden Baillio
Kelvin, I love that quote. I love that quote. me jump in. I love that quote because oftentimes I feel like we talk with a lot of engineers that see that had to go talk with business leaders in their unit that are just shoving off this concern of like, yeah, okay, we have an end of life software. Just go figure it out whenever it's a much bigger issue. like, this is stopping us. This old software, this tech debt is stopping us from delivering a better product or experience or solution. And so I really liked that quote. It's great. It's bigger. Tech debt is bigger than just the engineering department. And I like that.
Kelvin Del Monte
100 % 100 % Sometimes it's difficult to get the you know, the C level guys or the executives to to understand this but we have we have to make them understand because it's to their benefit not only to us as engineers or or product owners or you be a PM a product manager not only for us It's also for them, right? We're trying to help us Help you basically type of situation
And the next slide is another meme that I have, which ties into this developer morale, right? So you have engineers that leave your company just because of this technical debt that they have to interact with. I've seen this happen over and over again. And sometimes the funny thing is that the person that created
most of the technical debt is the one that escapes like this tiptoeing away from the house while the technical debt is sort of killing everyone of the team that is actually staying behind. And yeah, this ties in with, know, some of these guys that leave, they're not in technical debt, they are the technical debt.
Hayden Baillio
Awesome.
Kelvin Del Monte
So yeah, it happens. It happens. And it causes people to leave your company, your teams, for sure, engineers. So what can we do about it? It's a clear problem. It hurts our company, hurts our products, our people, our morale as a team. So I have some common pitfalls that I want to go over. So basically, we should start on what we should not do. These are things that I have done in the past.
And I want to issue a word of caution to never just don't try to do these things because you will end up probably in the wrong path. So only fixing technical debt reactively. This is an approach that is very naive, which is the approach that you'll say to your team. You'll hear this sometime in your career. Somebody will say, we'll just fix it as we go.
Or if you're in a file and that file contains some of the debt that is in question here, then just go ahead and fix it. No, this doesn't work. It affects the scope of, it has many problems. It affects the scope of what you're actually working on.
which could make you miss a timeline and then your fallback will be, I was worrying about this other problem that I found in the file. So it pollutes your scope. We never want that, right? When we're following an agile, you want to make sure your scope is nice and tight and not have these technical debt issues that may or may not.
up here whenever you open a file or are working on a section of the code. So this is not something that you want to do. That is not something that you want to take a reactive approach to. You want to absolutely take a proactive approach. first identify it, then plan for it, then gain, well actually identify it, write it down, get some buy-in from your team members, which we're going to talk about in the future.
Kelvin Del Monte
And that's you never do it reactively is a bad approach. Then the next thing is having no visibility, which if you're doing react, if you're doing it reactively, this also a problem. Like you only, know, or whoever reviewed your code that, that this problem was there and it was fixed. Your team doesn't know it. There's no way to track it. So no, not having visibility or any sort of priorities tied to them.
This is also something you don't want to do. And here is the king of the don't do ever. It's the over committing to massive refactors. I've done this in the past. I've been part of a few of these, especially during the beginning of my career where I was less experienced and more passionate, I should say. More and most definitely more naive.
in some of these things where I wanted to use the latest technology and I wanted to do it as fast as possible without really thinking so much about the business, which is what's paying the bills for you and your colleagues and securing so many things for your families, your customers are using. This is what's important. It's not this massive refactor that you're considering. So this massive refactor, even on, let's say that you are successful.
the chances of you failing are much greater. And even the people that back you on this massive refactor that you could do in the future, somewhere in the middle of this massive refactor, they, when they start hating really their daily lives, they're going to forget that they backed you. And because of all the pain that they're going through, kind of like when Israel went, left Egypt and they were sort of looking back and saying, Egypt was so great.
Of course, you're in the middle of the desert, almost dying, you can't find water. Of course, you're to look back and Egypt was an incredible place, right? But this is exactly what will happen. It's too much. will delay a bit. It will basically stop your team from shipping features because everyone is all hands on deck, sort of committed to this massive refactor.
Kelvin Del Monte
which is most likely, mean, all odds are against you, will most likely lead you into, put you in a position where you were the one that caused this, this massive refactor. And even if you miss it by, it was a huge achievement. You missed it only by two days or three days. You're in a position where everyone suffered too much and the business was in jeopardy and it's all because of you or whoever was backing this massive refactor. It's not the way to proceed.
really. And if this by any chance is the only viable way for your team to proceed, there must be a very, very good reason. Most of the times, this is not the way to proceed. And this is something that I learned from my career. And I put this quote here, which is the road to hell is paved with good intentions. You may have the best intentions for this refactor.
But listen, this is not about you or your friend that wants to use the latest technology. This is about your team. It's about you have to get consensus before you move forward. You have to make sure that you're doing things in a methodical way that everyone's agree with, agrees with, not just your good intentions. This will, this will lead you to a terrible, terrible path.
Okay, so moving on, tactics that do work. I've tried these and they work beautifully. They're sort of the inverse of what we just talked about. So we're gonna go into these in detail, but I'm just gonna list them here. Track depth, debt visibly, estimated, get exec buy-in, and then execute, which is this writer's concept. It's a bit of a nuanced way of executing, but I'll talk about that in a moment.
And that if needed, have to bring, if you have to bring in outside help. That's not something to feel ashamed about. And actually as our organization, it's kind of a perk for your employees. We'll talk about that in a moment as well. So, okay. Tracking debt visibly. So, I put these bullet points here for you. So, you have to be vocal.
Kelvin Del Monte
You have to very vocal with your entire team about debt. That you found that anything that you think the team should address, you have to bring it up. Bring it up in your team sessions. Whether it's stand up, maybe in the retrospective, maybe you have something, maybe in backlog grooming, you can start saying some of these things. Find a space here where you can...
call some of these things out and make it known to your team. You want to know with your team, this sort of ties back to the opinion factor from the beginning. You may have an opinion that this is dead, but you may have your other colleagues to explain to you why this is not dead and maybe you haven't read some sort of documentation. Maybe you're not familiar with this part of the code and why it was written like this. And there's...
documentation that will make your life easier. Maybe it's not dead. So first you have to get consensus whether it's official debt that your team believes is dead and it can be marked as dead, right?
To improve, to have this visibility, think about it. It has to be on your board. It has to be somewhere in your backlog. It has to be discussed during your backlog grooming sessions or it will be forgotten. So as an engineer, as a PM, whether you're a project manager or whether you're a program manager, maybe you're spending time on multiple projects.
used or a product owner, for example, everyone, even some executives, in my opinion, are looking at whatever your backlog tool is or your project management tools. So it's Jira, Santa, Trello, Monday, any of these tools.
Kelvin Del Monte
They have high visibility. In fact, that's the reason why they exist is to allow you to do your work and organize your work. technology, sorry, technical debt must absolutely be logged here and logged in a way that is actionable. So, you know, as you're documenting what the debt actually is, you have to partner with your project manager or with your technical lead.
or if it's yourself, then partner with your PM and sort of get these things logged and put all the information that you can to actually make it actionable, right?
It doesn't have to be done in one go, but this is what backlog grooming is for. Enter the details and then groom it as you go. Make sure that you make it actionable by and separate it by making maybe creating an Epic. I've done this in the past where you create an Epic in JIRA or some of these other tools. And it's an Epic with, you know, not a forever running Epic. It's an Epic where there's a limited amount of tasks that are in there that will solve one problem.
and you can treat it that way. So make sure you have it organized in however way you see fit in some other environments that we've used labels before, very label heavy environments that use JIRA labels a lot. We've used that before. However you like to organize it, make sure it's organized and visible to your team and being brought up on your team sessions. Visibility turns dead.
into something you can actually prioritize and work on. You can't fix what you can't see. Out of sight, out of mind.
Kelvin Del Monte
Okay, so first let's talk about cost estimation, is, okay, you have your debt sort of visible already, your team is talking about it, and your backlog grooming sessions, put a time effort on it. know.
You know, you may be doing story points, you may be doing some sort of other estimation, but it all boils down to some sort of cost, right? So this will allow you to sort of take this task that you think is important to do, that's slowing your team down, and you want to make it, you want to present it to your executive team, which is the next thing we're going to talk about. You want to make sure, you know, the executives, this is what they care about is...
How feasible is it to undertake this that you want to do? And they want to, you know, they think in numbers. They want to weigh it out and see if it makes sense to take any action on this debt.
or if it's something that can be delayed until the future. So you want to give them that cost, whether it's in time or however it is that you do estimates that your executive team will understand. You want to make sure you're partnering with your team and partnering with your project manager to make sure you're grooming these technical debt stories and putting some sort of estimate on them.
And then of course, this will take you to this path where you're have a super neat technical debt epic or several epics that you'll be able to present to your exec team. And then you can get buy-in, which is approval to actually begin work and some sort of guidance on how and when we can afford to begin this work. Some of these examples here that I put are.
Kelvin Del Monte
This bug exists because these are all things that have happened to me in some time in the past where I've brought up something like, hey, why did this bug occurred? Well, the bug occurred because we didn't have unit tests here. We didn't have intent test coverage here, which is something that we've been asking for. So bring it up to them. This is why technical debt, this is how technical debt is affecting you and your bottom line. And I assure you, they're gonna take technical debt way, way more seriously, right?
when you bring it up. And at this point, you would have completely actionable stack of tasks that have costs associated with them, making it way more easy for you to get that executive buy-in that you need while they're asking you to ship the features. You have to translate your pain, your engineering pain, your project management pain into something that they understand. Delivery speed, risk, know, risk on shipping features that make money for the company.
And last, so now you've got approval, how should you actually execute and move forward? You've gotten approval from your executive team to move forward. Now that you've gotten approval, maybe they were loose with their approval. They didn't sort of give you guidance and they allowed you do as you wish. Well, this ties back to the won't do's or don't do's, which is absolutely.
Do not do a massive refactor. Do it like this, writers. In high school, I learned that in the US government, or Congress, I should say, there's this concept of writers, which is smaller bills that are attached to large bills that are about to pass, or a lot of work has gone into them.
And they attach these small bills that sometimes have nothing to do with the bigger bill that's attached, that they're attached to. So kind of approach technical debt in this way as well, which is you're just reserving a few cycles that you're reserving on each sprint. This allows you to, you know, continue to deliver your features while at the same time cutting down on technical debt. I know this sometimes you cannot do this. You may not be able to do this, but this should be the optimal approach.
Kelvin Del Monte
Do it in small increments, so small continuous improvements. They will for sure 100 % compound over time. And whether it is whatever amount of time, six months, a year, you will see the difference. While you're continuing to ship features, your app will be much more healthy. And everyone is happy. You're happy as maybe the lead. Your team is happy because you're actually taking action as the lead, or you're taking action as a team.
and obviously your stakeholders will be happy because they're shipping features.
So this brings me to the last suggestion, which is bring in outside help if necessary, which is where we come in. know, here at Devs, this is our bread and butter. We help in, I'm actually gonna talk about exactly what we're doing in the next slide, but this is our bread and butter. So you can bring a company like us to help you with your technical debt.
We will focus on that while your team is, you know, shipping features. This is super useful for massive upgrades or maybe you're in support dependency hell and, or having to, you know, want to do a deep rewrite into some other technology or some other language. We can help with this and you can bring outside help for sure. This improves developer morale because it's of like a perk from your company. You're an engineer. You get to continue to ship features while.
your company's bringing outside help to do the things that maybe you don't find so interesting, which is solving all this technical debt. So it's super important to always consider this to bring in specialists. I want to tell you a little bit about us, Hero Devs. We've been around since 2018.
Kelvin Del Monte
We have 800, more than 800 customers from the Fortune, a lot of them from the Fortune 500, Fortune 100 companies. We specialize in, you know, out of support, supporting end of life software in many capacities. We have a great, absolutely great team. We've been doing this for a long time. Here are some of the companies that work with us. This is a...
you know, a feel-good slide, as my colleagues call it, which shows you, you know, we're in business. We do, we, you know, we have worked with all of these, with all of these companies and helped them do migrations. And also there is another way that we help these companies, which is through our NES, Neverending Support.
which is line of products. We just call it NES for short. So this solves technical debt in a different way. So I want to put in, as an example, the AngularJS Twangular migration. So a lot of teams, maybe if you were building your app in 2010,
2011, you were probably using AngularJS. But by the time you even finished your product, they had already moved on to Angular. So you couldn't possibly, maybe you didn't have the resources to migrate to Angular. So what do you do? Now you're stuck out of support. Well, never-ending support couples very well with our, obviously we can help you migrate, but you don't have to actually move.
We will extend the support for many of these libraries that you see here and more. If you reach out to us, we have more even in our offering. And yes, we can help you actually stay supported within your end of life software that you're using or library. And this also obviously eliminates that forced technical debt, which is, the technology that you're using is out of support. So it sort of creates that debt for you. So yeah, we are...
Kelvin Del Monte
Continuously expanding our offering and yeah, just I think Hayden how many products have we have we sort of released in the last? year
Hayden Baillio
Last year we released definitely over 20 new NES products. I think it's been cool to see a lot of that's driven by our customers and by the people that we already are helping with the Interlife library are coming to us and they're saying, hey, we need support for this as well. Could you all do that? And so we've had a lot of business or new product development driven by our current clients.
Yeah, always open to hearing about new needs. That's for sure.
Kelvin Del Monte
Yeah, there's a lot of interest and of course, if I'm coming to Hero Devs as a customer and I'm facing this massive migration that I cannot do, this is a lifesaver. So yeah, you don't have to actually do anything. You can continue to ship features even in your end of life. Even while maintaining your end of life software because at the time that you purchase NES, it will no longer be end of life.
Anyway, final tips and takeaways. Start small, make sure you make your technical debt visible. Bake it into delivery as much as you can. Get outside help if you need it. And don't chase zero debt. This is normal. This is a natural part of building software. It will always be there. Just manage it. I want to thank you for your time and I'll pass it over to Hayden for closing.
Hayden Baillio
Yeah, no, thank you so much, Kelvin. Thanks for I appreciate the overview. Tech debt is definitely something that everybody that we talked to and it's just prevalent everywhere, right? You can't get away from tech debt. I think the saying that we've started to adopt here is like, you know, as if you're adopting open source, then you're adopting tech debt. It's just how it is. It's the you're just adopting future tech debt. And I think you gave some great actual insights. We'll be posting the recording on our YouTube more than likely. And so thank you everyone for joining.
I know we're seven minutes over, we're going to have to, you know, if you have Q questions, please reach out to the individuals who, you know, invited you to this webinar or, or reach out to, to Kelvin specifically if you'd like. Kelvin, what's your, what's a, what's a good place that people can like reach you if they have questions about this.
Kelvin Del Monte
At this point, you can email me, kelvin at herodevs.com. Be happy to answer and connect with you.
Hayden Baillio
Kelvin at Herodotus.com. Thank you so much and thanks everybody for joining. Thank you, Kelvin. stay secure and start planning how you're gonna deal with your technical debt. Peace, heroes.
