Recently, Angela Mahoney, the executive director of RADWomen and creator of Forcelandia, joined us to talk about technical debt.
We enjoyed the conversation Angela had with our Serious Insights host, Kristi Campbell, so much that we asked if we could share a speech Angela gave on technical debt some years ago. The speech is called “It’s Payback Time: Eliminating Technical Debt” and was delivered at London’s Calling in 2017. Below is a lightly edited transcript of the presentation from Angela.
(The transcript below has been lightly edited for flow and readability.)
Angela Mahoney: Well, first thank you for coming to a topic that I think many people might look at and just give a huge yawn, right. Because technical debt isn't that sexy of a topic, but I'm going to tell you why it's important if you don't already know.
But first, I want to start with a small game. Everybody knows bingo, correct? You've probably played it once or twice. So we're going to do a special type of bingo. Because I want to know if you've ever heard or said any of these things.
For example, "Let's just get it into production. We'll fix it later."
Anybody?
"It's not in the budget.”
“We've gathered our requirements, but I'm so sorry it's not in the budget."
"I know we're doing an automation project, but let's just have them do it manually for now.”
Or maybe, "Not the sprint, but I promise we're going to do it in the next sprint. Okay?"
I think these are all things that we've either heard somebody say to us or that we have done. And it's embarrassing, but we all do it. Unfortunately, what we're doing when we say these things or do these things is we are creating technical debt.
I'm going to tell you a little bit about why I think I can talk about this subject.
I've been on the [Salesforce] platform for maybe 12 years. I started as an admin in a Spanish-speaking environment deploying mobile. And from there, I worked up into project management and I ran a platform for five years. So I managed a team of Salesforce developers, .NET developers, and some pretty kick-ass admins to make our platform work. When I left that about five years ago, I went into consulting.
So for five years, I was managing a platform of people and creating technical debt. And then as a consultant, I'll admit I created some of it too. We still do. But then I had to deal with debt that other people created. So it's a topic that's near and dear to my heart. I have experience with it. And it keeps me up at night sometimes.
I don't have hobbies. It's all Salesforce. So I've been running Forcelandia, it's like London's Calling geared towards developers. I co-founded a training organization to help women learn Apex, a Portland developer group, and then some certifications, which I'm in danger of losing until I get some testing done. But I really like what the platform can do for us and how we can help our users and our managers make it work well.
So, technical debt. This is a pretty generic explanation of what technical debt is. It's a concept. It's a concept of what happens when we try to push something in by writing simple code, for example. Or doing a simple configuration when something that takes a little bit longer is a better overall solution. It's where we cut corners. It's where we cram things in. It's where maybe we kind of lighten up on our testing just to get something out the door. It's a concept to try to describe all of this.
The goals for this session are to learn how to recognize it. We've done a little bit of that. Learn how to minimize it so that we can optimize our systems and have happy users, happy managers, and ideally get more tools and fun things to play with on our platforms.
Now a funny thing happens when you look at the different people in your stakeholder village. When we start generally at the developer admin level, we're pretty in tune with what our systems need. We have to be because we're responsible for them. We know where the errors are going to occur. We know when things might break. Ideally, sometimes they're unanticipated. But as we move up the food chain, if you will, up into the C-suite, it gets murkier. So the arrow gets darker, your upper decision makers’ ability to understand what is going on with the technical part of the platform decreases. I think if we all agree on that.
I know I myself said like, "Oh my gosh, they just don't get it. Why won't they say yes to my boring unsexy project to fix the system?" And then we've got the users out there. But fundamentally, while we all may not like each other or agree with the decisions that are made, we're all in the same ecosystem. We're all part of the same group of people that uses our system, but we have different pieces in it. So keeping that in mind, I'm going to go over a few different ways that we can work to minimize our technical debt. Watching our language, involving key people, emphasizing continual growth. Talk a little bit about how to visualize it or quantify it and then make it part of the process.
[Let’s start with] Watch your language. Mom was right. When mom said, "Watch your language, young lady," she's talking about a lot of things that we can still use today. So again, if we think where we've got our developers here, moving up to Mahogany Row, we're going to use different languages and different words to talk about what we're doing, which works. When you're in a very technical environment, there are going to be words that you use that people outside of your area don't. The same thing with people that are making decisions on a company-wide level, they'll have a different vocabulary.
It's like when I come over here, sometimes we all speak, well, we speak English. I don't necessarily understand British English sometimes. It's very fast. The accent's different. It's not unlike this. So we have to think very clearly about what we're saying, what words we're choosing. Case in point, when I was managing my team and we had to go present why we were behind and what the issue was that we had to resolve. I wanted to pull my lead developer on the .NET side in because I needed his technical expertise. He said, "Sure, just a minute." And I'm not joking, he grabbed a schema that he had printed on, 12, 16 sheets of paper taped together beautifully. It means nothing. It means nothing to the people that were actually going to make the decisions, but that's the vocabulary that he talked in. And that's one of the mistakes that we make, is we'll want to throw out a flow or we'll talk about things that don't understand. And we can't do that.
The reason is while they might not understand, they are people that are going to make the decisions, IT project managers, CIOs. They might not understand the words that we use, but they'll understand the concepts. So we have to think about that when we're trying to talk with them and sell our concepts because fundamentally we are selling a project that might not be the big shiny one they want. But it's definitely critical to the systems that we all use so that they don't fail.
The same thing coming down. When they're talking about cap rates or the ROI and using different words, we can't just roll our eyes in the IT department say like, "They just don't get it." They get it on a different level. So we have to find a meeting ground and really watch what we're saying. So again, I think this slide is very important and that's why I'm going to keep using it is we are all on the same platform. We're all responsible for the same platform, but we're going to approach it in different ways. And when we need a decision made for something that's not very sexy like technical debt, we have to think about what's going to resonate to the people that will assign those checks.
Along those lines, when you think about technical debt, it sounds pretty negative, right? Nobody likes debt. Does anybody like debt? It's not a good thing to have. So one thing to keep in mind is instead of going in with all fear-mongering, your system's going to fail, we're going to have downtime bad, bad, bad. Think about words that are going to resonate. Okay. Like we have a risk reduction plan. It sounds completeompletely like you're on top of it. Okay. Let's figure out how we can fit that into our risk reduction plan. "Ah, I have an optimization technique that I'd like to share with you," because it sounds really positive and forward-thinking and this is what managers like.
System stability process, whatever you call it, try to think of something happy sounding like forward-thinking to capture the concept of technical debt. Because this is something that's going to stick in their ears. Involve key people. Okay. So the slide that I have, that's our village. Those are the people that are going to be making sure that our system works. Even users when they say sometimes they might file a ticket if there's an issue. Sometimes they might create a workaround that you don't find until you try to do a feature request and find out that, well, six people do it eight different ways. Okay. Everybody's part of the village, everybody's responsible for it. So we have to make sure that we involve them.
When you're gathering requirements, for example, don't just focus on the group that is going to be using it. Especially if you're doing a proof of concept potentially for one business line, consider involving other business lines may be at a higher level. Because if it's going to be rolling out, you might discover something that's going to be strategic to your architecture. You want to know that early. So people will speak up, so involve them early. And we want to get that kind of feedback even if it's not going to be acted on, you'll have it in the back of your mind as you design solutions.
Alternatively, people will stay quiet. So you also have to find a way to make sure that you're recognizing who the different stakeholders are so that you can ask them. If they're ignoring your emails, that doesn't mean necessarily that they don't have something to say. It might be because they're uncomfortable with it or they're just completely snowed under, but you have to make sure that you're involving these people.
So involve key people, watch your language, emphasize continual growth. If you've worked on, especially on larger projects, some people might liken it too like, "Wow, as soon as it goes live, I'll get my life back." Okay. It's just like, "As soon as I have this baby, everything's going to be great" because you spend so much time working on something, it's born. That's when the real work starts, but I think a lot of us are way focused on deployment date. It's going to go live. We get to end our support. Woo-hoo. Life is going to continue. But what we fail to continually promote and recognize sometimes is the code never dies. Once you create it, it's going to be there.
Projects are never done. Okay. They might be deployed, they'll go live, but they're not done. Because processes are not stagnant. Business processes are going to change. New clients are required, new contracts are signed that will require that your system move with those. So when people have the concept that are writing the checks or doing the annual budgets that like we got project 2000 as done. It's not ever going to be done. So we have to make sure that those people that identify done, understand that there are maintenance costs. Okay. And the more complex your systems get, the more maintenance you're going to have to build into the budgets. So that's something that can be overlooked and you might sound like the squeaky wheel if you keep bringing it up and bringing it up and bringing it up. But people need to understand that concept when they're building budgets so that you can handle some of this.
What resonates to a lot of decision-makers is numbers. They're analytical. They want to build the pros and the cons, know what the no-go, go decision is. So there are a variety of ways that we can look at when we approach a fuzzy concept, like technical debt. Now if you Google it, you can find, for example for each line of code, you have that's I think $3.82 cents. And I didn't translate to pounds, or 542. There are studies that have been done on systems. In the grand scheme of things, those are arbitrary numbers. Why? Because the real number that you want to look at or two numbers actually is how much are you accumulating maybe in hours in your staff time or the dollars if you have to outsource something? Or if you have downtime, if you suffer a systematic failure because something broke and people can't get online, they can't work. Your clients can't get into their portals. That's a serious issue. Those are the numbers that are going to be more important when you're trying to convince somebody of what we've got.
So for example, ways to do this. Instead of keeping it in your mind if you have a ticketing system, use that. Maybe a different record type, for example, to say these are things we're accumulating. These are requirements. They got pushed into the next sprint that didn't make it because the budget wasn't there for whatever reason. You've got a way to track those. This is a bug. It might be a lower-level bug. Severity is less, but it's still there. You're just not going to fix it.
Feature requests. When the users say, "Gosh, wouldn't it be nice if." Keep track of those because those help people have confidence in your system that it can actually do what it's supposed to do. If you say like, "We've got technical debt, we really have to deal with that I have to go refactor a code." You're going to probably get met with lazy eyes. But if you say we've got 32 tickets that were filed this week, and that brings our ticket load up to 285, those are numbers that make sense to people. So if you can come up with a ticketing system, if you don't already have it to be able to provide those numbers, that's going to help a lot in increasing your ability to make your case for getting technical debt dealt with.
In testing as well, if you can automate testing so that you can discover things, as you're putting new things into production, for example. All of these will provide numbers or metrics that your decision-makers can use to do something that's not going to be related to the cool new project that they want to have.
All right. So then when you get those numbers, you need to make it a part of the process. And by this, I mean, if you have a project for example, where you're going to maybe automate the sales process. Finally, you're moving off of Excel sheets and Post-it notes. And you've got a budget and you've got a timeline and you've got executive support. And you know that you have to get something else in there or to get a system where you can say, "You know what, we're going to dedicate maybe 10% of our hours" or something like that to our system optimization. One, it sounds cool, and you're getting what you need out of it. But it has to be something that's built into your sprints or what your project plan is going to look like.
And resist the urge to put it, when you're looking at your priorities, don't put it at number four. Results will vary when you're looking at where you are in your company. But there's always going to be the bright, shiny, sexy thing that everybody is waiting to have. You might have some other really killer opportunity to work on, get the optimization in there. And then in many cases, there's the one little gimmie that somebody saw from a sales rep or a salesperson with Salesforce, and really wanted to get that in there.
So you've got things to play around with. But fundamentally, it has to become a part of the system so that you can schedule getting the bugs fixed, getting the code refactoring. Maybe catching up to the releases that are happening because those take time to get around.
Question so far? All right. Okay. So I'm going to bring it back to this. Our system, village I'll call it that. Because we have to stop thinking in an us versus them mentality. I'm dedicated to the system, I know what it does. I'm going to be writing the code. I'm going to be pushing it. While that happens down here, the people up at the top of the food chain, if you will, are very, very interested in it. Even if they don't understand it.
So I'll just do [this] as a quick recap.
Watch our language. So when we're thinking about the frustrations that we might have with our systems, the users are unhappy. We know that something's going to break because we might be reaching limits. We have to think about how we're going to explain this as we move up the decision-making process. Okay. Because we want to identify this and have it dealt with before something breaks.
Involve key people. We know who they are. We just need to make sure that we're talking their language so that we can communicate in a better way. And I think somebody mentioned that earlier communication is so key. But barking out the three-letter acronyms that we've got is not to make the case that we think it's going to make, no matter how well we understand it.
Emphasize continual growth. Projects are never done. Okay. It's unfortunate that sometimes a CEO might think we finished our big project we're good to go, stop. That's not going to happen. And we can't buy into that as well. We have to keep thinking about maintenance.
Visualizing it or quantifying it. Money talks. Being able to say how much we think we might be accumulating either in our potential forecasted downtime or how many cases we're growing or tickets are growing week by week. Those are numbers that people can work with. So we like those. You can chart them. You can make them into pretty pictures and graphs that help people. And then make that part of the process.
When you're looking at what your sprint is going to be, leave time. Even if it's a small amount of time, leave time in that, to do something that's going to help stabilize your system, rather than adding new features on or new shiny buttons, things like that that people want. This has to be built into the process, even though it's not that exciting.
And I think that's all I've got. If people have questions, answers, advice. I think we've all lived this. Any questions? Did I do a good job? Okay. That's it.