BT

Facilitating the spread of knowledge and innovation in professional software development

Contribute

Topics

Choose your language

InfoQ Homepage Presentations Dealing with Technical Debt in 2021

Dealing with Technical Debt in 2021

Bookmarks
44:26

Summary

The panelists discuss how they identify technical debt, how they make room to invest in paying debt down, and how they approach work to minimize future debt.

Bio

Renato Losio is Principal Cloud Architect @funambol. (moderator) Vatasha White is Software Engineer @LaunchDarkly. Kevin Stewart is VP of Engineering @Harvest. Marianne Bellotti is Engineering Manager @Rebellion Defense. Murali Krishna Ramanathan is Staff Software Engineer @Uber.

About the conference

InfoQ Live is a virtual event designed for you, the modern software practitioner. Take part in facilitated sessions with world-class practitioners. Hear from software leaders at our optional InfoQ Roundtables.

INFOQ EVENTS

  • April 4-6, 2022 (In-person, London), May 10-20, 2022 (Online)

    Learn how to solve complex software engineering and leadership challenges. Attend in-person at QCon London, (April 4-6) or attend online at QCon Plus (May 10-20). Save your spot now!

Transcript

Losio: We are going to discuss, what is technical debt? What is the extra effort needed to implement something new, with less than ideal code, or with code that is over-engineered. Also, we want to discuss what's the status in 2021? How we are going to identify problems. How we're going to address them. Hopefully, as well, how we're going to avoid them in the future. Because at the end it's still a very big problem for the development team. Apparently, there are some studies that prove that up to almost 22% of the development time is for technical debt. Usually, development teams don't really like from a morale perspective, from a productivity aspect as well to work on tech debt.

Background, and what is Tech Debt?

I'm Renato Losio. I'm the Principal Cloud Architect at Funambol. I'm an editor at InfoQ.

Just give an introduction of yourselves, and how we end up dealing with technical debt.

Ramanathan: I'm Murali Krishna Ramanathan. I am a Staff Software Engineer at Uber. I'm also the architect of Piranha, a tool for cleaning up code related to stale feature flags. I focus towards handling technical debt. In the last three, four years, I have been dealing with all aspects of technical debt at Uber.

Bellotti: My name is Marianne Bellotti. I am the author of, "Kill It with Fire," which is about dealing with legacy modernization including technical debt. It's based on a good four or five years I spent working in the federal government on some of the oldest computer systems in the world. Right now I run engineering teams for new technology as part of Rebellion Defense, where we work on AI systems.

Stewart: I'm Kevin Stewart. I'm VP of Engineering at Harvest, which makes time tracking software. In my role as VP at multiple companies, I'm always dealing with tech debt, sometimes small, sometimes large. Currently at Harvest, we have a 15-year old Ruby on Rails application. We are currently in the process of migrating to Google Cloud on GKE. I'm dealing with a ton of technical debt, and how to handle it safely so that we don't affect our customers.

White: My name is Vatasha. I'm a software engineer at LaunchDarkly. I've been at LaunchDarkly for a little bit over two years now. Throughout my career, I've dealt with tech debt, at all the companies that I've been at. At LaunchDarkly, we have a commitment to addressing tech debt by working on a percentage of keeping the lights on feature work versus new feature work. We reserve a commitment to work on 50% of KTLO work versus new feature work. Then, we also have things like flag archive athon where we spend some time on archiving old flags. That's one way that we address tech debt is by working on 50% KTLO versus new feature work. Then by having a completely flag archive athon to delete old flags throughout our code base.

How to Deal With Tech Debt

Losio: I'd like to start with a very high level question. I'm a developer, sometime a lazy one. I tend to sometime question myself, is technical debt really bad? Also, I need to think so much about identifying technical debt, and why should I identify first, and can I reduce technical debt even without knowing that I'm dealing with technical debt? Or, do I really need to understand first what technical debt is and start from there. Anyone has an advice?

Ramanathan: In my opinion, technical debt is not always bad, but the inability to actually track and identify what constitutes technical debt could be bad. Let me give an example. When we are trying to build a proof of concept or build something rapidly, there are certain aspects of software engineering practices that may not necessarily be followed. In those cases, it's ok to actually more rapidly get a proof of concept out and get a functional system. Then, when doing that, there needs to be clarity that there is some amount of technical debt that is being accrued, and then that needs to be tracked. Then there needs to be a plan for actually handling that technical debt going forward. It's like a delicate dance between how fast you move, and then trying to track this. Then periodically try to reduce this over a period of time.

Bellotti: I think it's really important for software engineers to break themselves of the habit of thinking that it is possible to write it right the first time, if you're just smart enough, and you just work hard enough. Because it's not just about, we need to build something really fast. Sometimes you actually don't know the product market fit yet. A lot of the abstractions and assumptions you have to make in order to make code modular and reusable, come from understanding what it is you're trying to solve, and what that fit is. You don't know what that fit is yet, you're not going to build out those abstractions. You're going to eventually have to come back when you do know what that fit is, and restructure the code so that it's more reasonable and efficient. We generally call those things tech debt, but you would never be able to see it or foresee it before you actually know what the fit was.

Stewart: I'd also agree that technical debt being good or bad, it's a very binary distinction. You really should think more about the level of impact that the technical debt potentially has, and whether or not you're going to address it. I think sometimes engineers, and I definitely was guilty of this myself, just seeing something that I thought was technical debt, I thought something we need to be fixed. It wasn't the most important thing that we need to be working on right now. The level of impact of that thing was really small. Getting a more nuanced idea of where this technical debt fits on the spectrum is definitely highly important.

White: It really does depend on product requirements. Not all tech debt is bad. Say, you have the product requirement to build something very quickly. Inherently, you're going to have to make some tradeoffs to go ahead and build that thing as quickly as you would like, so you're going to introduce some level of tech debt. What's important is outlining that as a part of your tech spec to say, this is an area of code where we might have introduced some tech debt, let's file a ticket to address it later. As long as you're keeping track of what that tech debt is, and you have plans to address it later, then it's not necessarily bad, but you should be really deliberately making those choices.

Ramanathan: In many cases, it's not practically feasible to get rid of all technical debt. Let's say we take unit test coverage covering all regions of code, we may be able to cover all lines of code, but if you consider all parts in code, then you will not be able to have enough unit tests to actually cover them. It's also not feasible to reduce tech debt to zero at some point in time. Having that tracker and prioritizing that becomes key.

The Value of Addressing Tech Debt

Losio: The goal is try to avoid it getting out of control and it keeps increasing, more than really trying to bring it down. Do you assume a natural minimum level of technical debt has to be there because the work required to address it will be much more significant than the value that it's going to bring basically.

Ramanathan: That's right. There is some amount of threshold, some leeway that we give to engineers and teams, so that they can try to cap the amount of technical debt for their teams and organizations, and use that time to actually build newer features.

The Tech Debt Firehose

Losio: I have a tweet that I read last week from Eric Elliott. I want to read it to you and see if anyone has any comment about. "Beware of the tech debt firehose: often the fastest feature builder. Managers love them, but they slow down the rest of the team with poor planning, inscrutable code, test coverage, and no docs?" Any feedback? Is that true? Is that too strong? Is that reality?

Stewart: I'm probably biased because I disagree with Eric on a lot of different things. I also disagree with the managers love the fast feature builders. That's definitely not true for the stable ones.

Bellotti: I think sales teams love fast feature builders.

Stewart: Sales teams, yes, not engineering managers. That would be the first thing I disagree with. Like everything, it's not so black and white. You need people who can build features fast for certain things. If you're not putting in the controls to manage technical debt over time, to assess how your quality is doing, then yes, you're going to be in a world of hurt. That doesn't mean that you penalize the people who can move quickly. You want them to up their quality game a bit, and not take too many shortcuts. It's a delicate balance, and managers are more responsible for ensuring the final outcome. I only 10% maybe agree with Eric on this one.

How AI and Machine Learning Can Address Tech Debt

Losio: I'm actually coming from a very different background right now. I'm coming from more like cloud technology, mainly working with AWS. One thing that really surprised me recently was that push from a cloud provider to bug bust, and all those initiatives to reduce bugs and reduce technical debt by $100 million using AI basically, using machine learning, using their product. I was wondering how much is that marketing? How much can AI, machine learning really help in addressing technical debt or reducing it at least, or giving a hand to the developer, not to just be sad in a corner, try to address them alone or have some help somehow?

Bellotti: This is so interesting, because of what's going on GitHub's Copilot right now and licenses. It's like putting aside even the legal side of it. If your machine learning, AI solution for handling bugs or technical debt, it's just arbitrarily reproducing chunks of code. What is the quality of those chunks of code in terms of security vulnerabilities, in terms of best practices? When people talk about, let's use machine learning to solve these developer facing problems, I feel like we're just adding another layer of problems on top of the existing problems, rather than solving the existing problems. Tech debt is a lot about context. First of all, it's probably too vague of an umbrella term, in many cases. A lot of what we consider to be tech debt is actually this system is 2 years, 3 years, 5 years, 50 years old, with the way we built it the first time we assumed a couple of things that are no longer the correct assumptions. Now we need to change direction in order to continue to develop new features. I don't know that there's any AI algorithm in the world that's going to be able to tell you that your context has changed, and like this is what the code should look like given that new context. I'd be super impressed if there was, but I don't think it exists.

White: I would agree with that a lot. I think that fixing a million bugs is a significant step in the right direction. It does feel this is very much like a marketing campaign, if it takes for you to do a marketing campaign to fix the million bugs then you're already in a bad state. Then what I would like to add is that, I also think it's a marketing campaign because I'm really interested to understand how they arrived at they're going to fix a million dollars' worth of tech debt. I'm not sure how they calculated that.

Bellotti: It's actually just one problem that cost them a million dollars right now.

White: Maybe.

Ramanathan: I actually think the bug bust is a fascinating idea. This is my reasoning. Typically, technical debt gets introduced because the team that is actually building a piece of software doesn't have the time to actually handle that debt. There are two levels, like one is a specialist, so a set of specialists. Then we can have generalists who actually can operate on any piece of code, and they are probably more cost effective. We work with the generalist to actually handle things like detecting bugs, or fixing bugs, and then have the specialist review this and then give a green signal. You reduce the time taken by the specialist to actually handle tech debt by providing support through generalists or even through automated tooling. In fact, at Uber, we also had these incentivization mechanisms wherein general developers can just come in and contribute to addressing tech debt that is probably owned by specific teams. Then the final approvals are by the actual team that owns that code. We can integrate those two things. I think it's more than a marketing campaign. I feel it's like a valuable thing going forward and probably an approach that will be replicated across other organizations as well.

Bellotti: I would add that like going back to the firehose issue, for me, it's not about speed. It's about isolation. A developer works fast or slow, I don't necessarily assume that they're producing a lot of tech debt. When I have an engineer, who's hopping around from project to project, from area to area, always working alone, my assumption is that is creating a lot of tech debt. Because if you're not transitioning your knowledge about what you're building and how you're building it to other people, then the odds are you're not building it in a sustainable way that other people can parse.

Who Should Work on Tech Debt?

Losio: There's one thing, Murali, I really liked about the example of AWS, but I was thinking more about the positive impact on the team. In the sense that maybe those competitions, those kinds of games help as well, because usually we have that connotation, tech debt as well affects morale of the team and has a negative impact. One question that, of course, comes up when you mention that, I'm curious if any of you has anything that you mentioned, for example, having to deal now with a big migration with a lot of technical debt? As well the example that Murali gave of a different developer. Is it always better that it's a different developer addressing the technical debt, or is it actually better if the original team that introduced it, or the original developer that introduced it works on it again?

Bellotti: Sometimes you don't have the option. Sometimes the developer isn't in the mix. I don't like patching in solutions to solve problems that avoid the actual problem. I feel like getting a special team that comes in to manage technical debt just basically enables the original team that created the technical debt, to continue to create technical debt. My preference would be the people who own the code and built the code originally will manage the code long term. They are the owners of it, rather than having a team that's there just to manage technical debt, for sure. Sometimes you don't have that option.

Stewart: I'm probably going to be the broken record on this in terms of saying it depends. Because, like Marianne said, sometimes you don't have options, like the original developer may not be there any longer. I think the one thing I focus on is more about having collective ownership of the code with teams rather than relying on individual engineers. I make it a habit to set up my teams so that no one person is the arbiter of any particular part of the code. Because to me, that's the overall risk is one person has all the knowledge. Then, if they walk out the door, you're stuck. We try to rotate people working on different areas of the code to get more familiarity. I haven't found any patterns that say that the people that originally worked on a system are the best ones to reduce technical debt. It's more a matter of, can the people who are looking at the problem, understand the context of what this code was trying to solve? Can they come up with a better way to do it to reduce technical debt? Sometimes a fresh pair of eyes is needed, versus having the same people working on it over and over. It definitely depends on the situation, the code base, and what control you actually have over the situation.

White: I would like to echo what Kevin said. I think it's super important to highlight that you don't need to be an expert in that area of the code to address tech debt. Sometimes, in often cases, you need a fresh pair of eyes to figure that out. Everyone should feel empowered to address tech debt. You don't have to be the author of the original code.

Best Ways to Track and Address Tech Debt

Losio: I see one that, for example, is a million-dollar question. It's like, we agree, it's a nice point that technical debt is not binary, good, bad, as long as you keep track of it. What are the best ways to keep track of it? What are the best ways to gradually address it? Do you have any specific advice coming from different backgrounds, different examples?

Ramanathan: I'm a big champion of automated tooling in this space. There are various aspects that can be automated, in terms of tracking tech debt across organizations. There are toolings available for that. Trying to find the appropriate tooling and workflows, and then setting it up so that each team can actually track it going forward, will be a good first step in actually reducing the technical debt over time.

White: We have some things at LaunchDarkly that are really different from any of the other companies that I worked at, that I alluded to in my introduction. One thing is the concept of how much time you want to spend on things that are considered tech debt versus things that are considered new feature work. We have 50% of our time dedicated to KTLO, or KTO, keeping the lights on work. It doesn't mean that it's all tech debt, but that's anything that's not new feature work. That's like bug fixes, support escalations. Anything that's not new feature work, that's KTLO. We reserve 50% of our time to work on that. A lot of the times, we are inherently addressing some tech debt in some of those bug fixes.

Then another thing that we do is that we have something called a flag archive athon. At LaunchDarkly, one of our fundamental values is always be flagging, that's one of our engineering value is we flag everything. If it's just like you adding a button into the UI, I guarantee there's a flag behind this new button, because we flag at the tiniest level. Because we do that, that means that we often end up with a lot of flags, and it gets hard to maintain those flags. We have something called the flag archive athon, which basically, it's a competition to see who can delete as many flags as they can in a week, to clean up the code. You can start to employ practices like that. When we're writing a tech spec, we also have the section inside of our tech spec that's called like, does this feature introduce any new tech debt? You call it out when you're planning the project. During the planning phase, you'll know directly if that project has any tech debt. Then, what are the plans to address it? I think if you call it out during the project, that's also really helpful.

Stewart: I would address it from a slightly different angle, because I have to do a process stuff more at the time. I know engineers generally get frustrated when their technical debt that they want to address and there never seems to be any time to actually address it. There's always something more important that has to get done. What I've discovered over the years is that it's best to build in timing your processes correctly for addressing technical debt so you don't have to negotiate for it all the time. The argument I've made at multiple places is that, generally, especially if you're like an enterprise software, frankly, people aren't buying in Q4, so why don't we chop off that period of time to allow engineers to address tech debt. Because you're not going to introduce any new feature. You're not going to be able to sell anything at that point. Everybody's looking towards the holidays. That's actually worse. I built into my process that whatever increments that we're working in, the Q4 increments are going to be completely dedicated to tech debt. That gives dedicated time for the engineers to bubble up the things that they think are the most important to work on, and they have a dedicated amount of time to work on it. That helps with both keeping track of it because the engineers know exactly what they consider particular problems, but also providing the time and space for them to actually address that in a sane way. Before we have to get back on the feature cycle all over again.

Losio: I'm actually quite impressed that you would mention a specific amount of time, like you mentioned 50% for not product feature.

Distinguishing Tech Debt from Spaghetti Code or Bugs

How do you really distinguish as well, a technical debt from spaghetti code, from a bug? Of course, it is easy to say I'm not developing and we're not adding a new feature, but you're just doing bug fixing, and then the tech debt ends up not done again, and postponed again. How do you actually define tech debt, in a sense, how you discriminate? Do you have any advice?

Bellotti: I would say that a whole lot of tech debt is that there is a simple and direct way of accomplishing a thing that you cannot take advantage of because of existing code and existing structures, ergo, you must go around a circuitous route to get there. I think that the secret to managing tech debt really comes down to having really great empowered managers. Every process can be subverted. Every metric can be gamed. Every automated tooling can be either turned off or ignored. They really need people who understand the value in keeping tech debt at bay and are willing to invest in it, and fight for it.

White: I think from the engineering perspective, the one way that I had been fire is think about that one part of the code that nobody wants to touch. It's probably because it has high amounts of tech debt, so just identifying those codes. I can think of parts of our code at the top of my head where I'm like, "Don't want to work on that part of the code." I'm sure that every engineer has like that in their head that they know exactly what part is a little gnarly. Those parts are normally tech debt.

Bellotti: This makes me want to survey my engineers now like, which part of the code do you not want to work on versus the part that you really want to work on?

When Tech Debt Can't Wait Until Q4, What Happens?

White: I think that we should do something like that at LaunchDarkly. I forgot to mention too before, when Kevin was mentioning, like making sure that you have Q4 dedicated for tech debt. I think that that's super important. What I wanted to ask you, Kevin, because it's a little different from our process at LaunchDarkly. We have something called Focus Week, which is every quarter, we spend a whole week to focus on whatever we decide. Usually, that's tech debt. We have four weeks in the year where we're addressing it, in the business year. Have you ever felt like it couldn't wait until the fourth quarter? How did you handle that?

Stewart: Absolutely. That's one technique. The fourth quarter approach is a giant block of time that we get to address it. You have to do tech debt handling during other parts of the years. There are things that just can't wait. Our process is some form of agile, but we work on six-week cycles with two-week breaks in between. Usually, in those two-week cooldown periods, that's also another opportunity to address more near-term technical debt that we have to handle. We built it into the process that way. There's different scales of tech debt that we handle. Short term or high priority tech debt gets handled across the years, usually during our cooldown periods when we're not dedicated on feature work. Then bigger things that are going to require more time but are not really impactful or not going to cause a problem right away, those are the things we defer to that Q4 time period. We try to blend it a little bit.

Ramanathan: Actually, we follow a slightly different model. We handle technical debt in a continuous cycle, rather than allocating certain blocks of period. We consider tech debt as a year-around activity. Then every sprint, there is some amount of time actually dedicated to improving the metrics surrounding tech debt. That's where I think the automated workflows come into picture and help us, rather than have a slot where all development work stops. You continue this, and then at the same time, also get rid of technical debt. That's another study that we have followed. We have also looked at fix-it weeks. I think the fix-it week is a common strategy across organizations. It is actually quite helpful too. It depends on the tech debt activities that you are looking at.

Stewart: It also depends on what type of company or what type of product you have, how big your company is. You have to adapt the strategies that Matt does to your organization and culture. There's no one-size-fits-all to addressing technical debt.

The Correlation between Tech Debt and Feature Flagging

Losio: As Murali talked before about Piranha, we had as well Vatasha talk about feature flagging. What's your general opinion about feature flagging and technical debt? Do you see a relationship? Do you see that any feature flagging is a technical debt long term?

Ramanathan: The feature flagging concept itself started off quite effectively to handle technical debt. Because the amount of time you have to take to actually merge multiple branches to get a single version is quite time consuming. What we have noticed in experiences like with adding more features, and more feature flags, it actually starts introducing a different technical debt. In fact, the talk that I gave earlier, specifically addresses this problem of handling technical debt. In my mind, there are benefits of feature flags. Using feature flags has to be done carefully, with a clear understanding that it's going to add to developer complexity. There needs to be strategies to handle that complex team, whether it is deleting their code, or even things like the cyclomatic complexity, or adding unit tests associated with the feature flag. There are other aspects of developer tooling that needs to be in place while using feature flags, otherwise, we are going to run into similar problems with feature flags as well.

Stewart: Feature Flags are fantastic and are a great tool. I think we've all learned this from Spider-Man, "With great power comes great responsibility." That's my advice about feature flags. Be responsible with it.

White: I would agree with that. Not all feature flags are actually tech debt, though. There is this concept of entitlements. Say you have an entitlement as like you want to roll out a new feature to a subset of customers like premium support or something like that. That's an entitlement flag. That permanent feature flag is going to live inside of your code. That one is not actually going to be considered like tech debt. That's actually just a part of your code. Whereas, if you have new flags that you're introducing to integrate into new features that are going to eventually go away when those features get turned on for everyone. Then I would say those kinds of flags do add some tech debt to the code, but not all flags are going to do that. It really depends on if the flag is going to be a temporary feature flag, or if it's going to be a permanent feature flag.

Identifying Technical Debt versus Legacy Code

Losio: People are asking about mixing up technical debt and legacy code. It's something that I was thinking as well, when I've thought about technical debt. If you say, somehow even a different concept, when I think about startup environment, or how it's addressed and how it grows versus more enterprise scenario, or company with maybe code that is 10, 15, or 20 years old. What's your opinion about how to identify technical debt versus legacy code, and how to avoid tech debt? Do we just consider everything the same that sometime happen in development?

Bellotti: My rule of thumb for making these conversations easier is that legacy code tends to be internally and logically consistent, because it was built in the same time as part of an overall initiative with a certain set of requirements and assumptions. Whereas technical debt seems to have like, we did it this way in this part of the code, or we did it this way because it was faster in this part of the code, or we changed this in midstream. It has these inconsistencies in approach, and assumptions that are piled up, like a core sample where you have multiple levels of sedimentation. On really old systems, you do have both. That is what makes it very confusing for people, is to figure out, what is tech debt and what is legacy? I think the same management structures are effective at helping engineers resolving both. On this front, I think that there is a difference, but it's not as critical to the conversation that people are strict about what that difference is, than some might assume.

Stewart: I think the distinction doesn't really serve much purpose because the legacy code may have made perfect sense and then perfectly cohesive at the time it was written. Your requirements change. Your needs change over time, and now it may have turned into technical debt as you're trying to do new things, and you're working around some of these legacy assumptions. Again, it depends, but I think trying to make hard lines between what's technical debt, what's legacy is probably not the best use of time. It's more about what's the impact this code is having on you and your business that is really the thing to be addressed.

Losio: At the end of the day, people still need to address them and is probably a different approach on the developer side, that usually it's not the same developer having to review that legacy code, anymore. At the end of the day it's, today it turns into a technical debt if I need to address it.

How Different Companies Handle Technical Debt

Is anyone experiencing different ways that technical debts are addressed, or the way people care about technical debt in a younger startup, or younger company versus in the concept that right now we need to go to market first, we need to become big in the next three years, so who cares about technical debt? We'll think about it later on, when we have 2000 developers. Or the approach is more or less similar in any company?

Ramanathan: I think it depends upon the stage of the company. A startup is probably accumulating tech debt, and then trying to get to market fast, trying to make a business out of it. Then when it reaches an enterprise level, it becomes much harder to be in that mode. You have to consolidate and make sure that you put in processes and systems in place, so that you can maintain the systems for the longer horizon. They still continue to accumulate technical debt, because any software development process involves a process, but they also try to get rid of some technical debt during the enterprise stages. It depends upon the stage where the company is.

Bellotti: I think when you're a young company, the feedback loop between engineering and sales is way more important than when you're a much older company. I have yet to find a salesperson that understands that when a prototype is built, it's not necessarily, now we can build on top of it immediately. You do make those tradeoffs when you're starting out, and you're just trying to feel around what the product could be, and what the best fit is. It's really important for sales teams to understand that the thing that you've given them in those early stages, you may actually need time to go back and retread that terrain and do it over again. That communication between the business side and the engineering side is way more critical at a young stage than it is when you're a much more mature company and have a little bit more of an established product line.

White: I would actually say that when I was at a bigger company, we didn't have a process to address tech debt. For me, a lot of the times I never really drew the distinction between legacy code and tech debt. To me, they're synonymous a lot of the times because the context of that legacy code changes, like Kevin says, so inherently it becomes tech debt when you try to build upon it. When I was at a larger company, we just had this notion of like, "Yes, it's legacy code." It was just hard to work with. There was no process or no thought of changing it. It was just that's the way it is. Whereas being at a startup now, I felt like we think about tech debt very often. We think about ways to address it. I do find that being at a bigger company, like at bigger companies sometimes you just check it up to say, this is the way it is. Whereas at a startup, you still have the space and the autonomy to actually make that change. I think it really just depends on the company.

Failure to Address Tech Debt and Developer Churn

Losio: Actually, I find it interesting that you mentioned that they had no process in place or any way that the company highlights technical debt. People tend to agree, tend to notice that many companies don't even have a definition of what a technical debt is. They don't even take the problem seriously. As well, I noticed, how we said from the developer side, it's not just a morale thing, it's a decision choice as well. I was impressed by how many comments there are on Glassdoor about, "Massive technical debt in this company, stay away." I find it quite interesting, then if the company is really addressing technical debt, or it's just trying to present a good side of the company to still attract reasonable developers. What's your experience with that? If you have an experience of people leaving, not for much technical debt, but for not giving the chance to the developer to address the code and just don't have the time or a process in place.

Bellotti: When I see comments like that on Glassdoor, what I hear is this is not an organization that values its engineering talent and empowers them. I think that's the real problem there. It's not the debate on whether or not there's an appropriate level of technical debt, it's that people feel like they should be doing it a different way, a better way, and they are constantly being frustrated by being denied the opportunity to do what they consider to be their best work.

Stewart: I'd also say that probably also hints at some lapses in management as well, because the engineers may be getting frustrated by their manager's inability to get them the space to work on technical debt. What I've seen over again, is that people take very, I'd say, naive approaches to trying to address technical debt, and say, "We have this technical debt we need to address." Meanwhile, the business folks don't know what that means. They can't understand, how important is this? How is this higher priority than the five features that I want to make that will increase our revenue by 10x, in the next six months? That usually indicates the manager is not really making strong arguments about why this technical debt needs to be handled. That's why I emphasize you got to build it in the process to some degree, because if you're basically trying to address some infrastructural problem, but can't communicate well enough to the people that are making decisions that you need to address it, you're going to get shut down. Then, engineers, in turn, realize how important this is. See that it's not getting the attention it deserves, and they're like, why do I want to stay in an environment that doesn't value this thing? That to me is lack of managerial savvy to get that stuff pushed up and prioritized? I can definitely reflect on what you're seeing on Glassdoor.

Incentives to Work on Tech Debt

Losio: Plenty of developers leave when code is full of technical debt, and all they do is maintenance and no new product, and no product or feature. In the end, that's a key point for many developers. The point is how to find that fine balance between, I want to address technical debt so what's the first step that a developer should do to get to the next step, to try to improve both the morale of the engineering team, but as well, to go in the right direction? It's easy to say, I don't want to have technical debt, but usually it's there for 10 different reasons. What will be the minimal suggestion you'll give someone to start working on it tomorrow?

Bellotti: Find a way to structure the conversation in terms of value add. Is this going to make things go faster on developing of new features? Is this going to eliminate performance issues or reliability issues? What is the benefit the organization gets out of it? Because there is some truth to perfect being the enemy of good. You can have the most beautiful tech debt-free code, and if the business goes out of business, because they can't sell anything, it doesn't matter in the end. You got to really link it very strongly to the value to the organization.

Stewart: Learn how to speak in terms of business value and impact, instead of just focusing on the technical issue, because you got to know your audience. If you're talking to an engineer, great, you can talk to him about the technical debt in technical terms. If you're talking to a product manager or a salesperson, you can't lead with that. You have to really translate that into, what is this going to impact in terms of things they care about, whether it's customer experience, whether it's sales? Translate that technical debt into the impact in their language.

Losio: Michael just wrote, applying dollars to tech debt has a cost to the company to show basically the value of the work done. It's like, really translate that into something that matters to the company, or that they can understand.

 

See more presentations with transcripts

 

Recorded at:

Dec 02, 2021

Related Sponsored Content

    Related Sponsor

    Developer Workshop: Module 2 - CI/CD Pipelines.
    Join experts to learn how to implement well-engineered CI/CD pipelines that consider governance and traceability from idea to production. Watch Now!

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT