[Title slide 1. Blue CAI company logo with tagline “We power the possible” appears in middle of screen. Company website www.cai.io appears at the bottom center of the screen]
[Title slide 2. White background with text centered in the middle of the screen that reads: “Webinar On-Demand. Maximize the potential of your applications and minimize technical debt”. The blue CAI company logo with tagline “We power the possible” appears underneath of this text towards the bottom of the screen]
[Presentation slide 1. Slide features the CAI logo and slogan "We power the possible” on the top left. The text below "Webinar. Maximize the potential of your applications and minimize technical debt" is displayed prominently. The background image shows a man in an office environment working on a monitor, with graphs, codes, and data displayed all around him. The name "Jen Boyer" appears in the top right corner of the slide, alongside a photo of a talking head, indicating the speaker.]
00:00:06 - 00:00:24
Jen Boyer
Hello everyone. We're going to go ahead and get started with our webinar today. So welcome. We are happy to have you here and participating in our webinar entitled: Maximize the potential of your applications while minimizing technical debt.
00:00:25 - 00:00:51
Jen
My name is Jen Boyer, I'll be your host for today. I'm thrilled to be here with you and work through this exciting conversation. A little about me, I've spent my career in IT consulting, performing, managing, and now partnering with leaders in IT organizations to develop and implement people plus technology solutions that really drive business results.
00:00:52 - 00:01:20
Jen
The majority of my career has been on the software side of IT, so maximizing the value that you get out of your application portfolio is a subject that's near and dear to my heart and something I've worked with many companies in different industries on. Today's webinar is going to be a deep dive on the subject of technical debt. We'll talk about what is it, how to build a strategy around it, and how AI and automation can help.
00:01:21 - 00:01:52
Jen
Whether you're here to sharpen your skills, build out a plan, or just get some new ideas, you're in the right place. So let's take a minute before we get started, just go over a few housekeeping items. The webinar is scheduled for one hour. We'll spend the first half having a discussion with our panelists, followed by a 20-minute Q and A session with the audience. Please feel free to use the Q and A feature on your screen to submit your questions, and we will address as many of them towards the end as we can.
00:01:53 - 00:02:12
Jen
Lastly, this session is being recorded. A replay will be made available to all of those who attended. You can feel free to share that out with your peers, and anyone who may have missed it today. So without further ado, let's go ahead and introduce our speakers.
[Presentation slide 2. Slide title is "Meet our guests." Below the title, there are three circular placeholders for guest portraits, each with a name and title underneath. From left to right: "Jen Boyer, Sr. Client Executive, CAI" with a blue tag stating "Moderator": "Matt Peters, Chief Technology Officer, CAI": "Amarjeet Singh, Executive Director, Solutions & Innovation, CAI." The bottom left corner features the CAI logo and tagline "We power the possible.” The name "Jen Boyer" appears in the top right corner of the slide, alongside a photo of a talking head, indicating the speaker.]
00:02:13 - 00:02:52
Jen
We're honored today to have Matt Peters, Chief Technology Officer for CAI With us. Matt is an expert in innovation management, flexible and agile delivery and organizational psychology. He comes with a wealth of knowledge and experience having led the technical re-platforming of CAI's enterprise services and building centers of excellence in hyper automation, cybersecurity and artificial intelligence, among others. Matt leads CAI's technical services delivery, operations, application development and security. So we're very fortunate to have them here. Welcome, Matt.
00:02:53 - 00:02:44
Matt Peters
Thanks.
00:02:55 - 00:03:18
Jen
Alongside Matt, we're excited to have Amarjeet Singh, Executive Director of Solutions & Innovation for CAI. Amarjeet is a seasoned professional with more than 25 years of experience in the industry. He specializes in application management, digitalization, strategic outsourcing, custom solutions, and P&L management.
00:03:19 - 00:03:54
Jen
He has an extensive track record of executing large scale transformation, and managed services programs across diverse industries, spanning multiple geographies, practices, cultures, and technologies. Amarjeet believes in the art of possibility and takes constant steps towards problem solving to achieve delivery excellence. In his current role at CAI he's responsible for developing innovative and next generation solutions to solve client problems. So welcome, Amar.
00:03:55 - 00:03:56
Amarjeet Singh
Thank you.
[The presentation closes and there are three boxes on the screen, each containing a name and a speaking head. Jen Boyer’s name and talking head appears on the top left: Matt Peters’ name and talking head appears on the top right: Amarjeet Singh’s name and talking head appears directly below them in the center of the screen.]
00:03:57 - 00:04:31
Jen
All right, let's go ahead and kick things off. So let's start out just by level setting. Technical debt means different things to different people. So why don't we try to level set a little bit on terminology. Gartner defines it as accrued work that is owed to an IT system and is a normal unavoidable side effect of software engineering. Teams borrow against quality by making sacrifices, taking shortcuts, re-using workarounds to meet delivery deadlines.
00:04:32 - 00:04:53
Jen
I've also heard it referred to as items that are deferred, that impact systems resiliency or performance, things like upgrades or patches. Or maybe a system was very effective at one point, but technology and standards have evolved, and so it's no longer, it's now considered technical debt.
00:04:54 - 00:05:05
Jen
So Matt, as a CTO whose had to deal with this, both internally within CAI as well as with our clients, how do you define technical debt?
00:05:06 - 00:05:24
Matt
I'd say Gartner's definition largely aligns with our experiences. When we think about technical debt, the way that Gartner characterizes the work yet to be done is certainly appropriate...
00:05:25 - 00:05:26
Jen
Did we lose Matt there?
00:05:27 - 00:06:01
Matt
Yes. So in that regard, when we're really looking at systems and applications and thinking about debt, CAI is a privately held organization, one of the powers behind the work that we get to do is that we're quick and we're nimble. So we do a lot of development on a minimum viable product methodology. That's essentially an approach that suggests that you're taking on a lot of technical debt intentionally so that you are not over investing in the development of whatever you're building before you can demonstrate its value.
00:06:02 - 00:06:31
Matt
So for me, when I'm thinking about technical debt in our organization, half of it is really just understanding where it's coming from, because that allows me to work on controlling and communicating the expectation management for that debt with the rest of the organization. I've run into a lot of companies, a lot of scenarios where a minimum viable product was being built out. Early users feel really good about it, the investment strategy starts to feel like this is good enough, we can release it, everything will be fine.
00:06:32 - 00:06:53
Matt
And the point behind it is, "No, if we want this application to scale, there's still more that needs to be done. This is really targeting a narrow deployment and we need a wide deployment." Things like that. So I find that being able to categorize technical debt in those kinds of ways gives us healthier ways to talk about them across the organization. So that automatically puts us into one approach toward handling technical debt.
00:06:54 - 00:07:28
Matt
But the other thing is that CAI is a professional services firm. So for our world, much of the technical debt that my team has to work through is forced on us by our clients. We effectively inherit a lot of their debt. So that can be in the form of legacy platforms, unsupported operating systems, systems and utilities, that to your earlier point, Jen, patch management can't be automated, so it has to be manual. It holds onto a lot of labor, because we inherit so much of that in the context of any engagement that we might get involved in.
00:07:29 - 00:08:04
Matt
And a lot of the time, CAI is able to help mitigate that debt for the client, but sometimes that's just impossible. So the last way that we tend to think about technical debt is, is it resolvable or is it not? And if it is not, then how do we make it the least painful that we can? And oftentimes that really comes from introducing some automation technologies and things like that. If we're talking about a system that can't be remotely patched, that doesn't mean that an RPA solution cannot patch it on your behalf. So we look at options and opportunities like that.
00:08:05 - 00:08:41
Matt
And then we also tend to really think about when we get involved in early engagements with clients around code reviews, and how we handle those so that we're doing code reviews that also incorporate integrations, and incorporate dynamic test case development, because those methodologies help us find technical debt that no one knew about quickly and puts us on a path to being able to address it. So a long-winded way of saying when we define technical debt, we kind of agree with Gartner, but we need to be able to live in a couple of categories that almost make technical debt seem appealing at the start when it never really is.
00:08:42 - 00:08:52
Jen
Okay, great. Amar, how about you? You've worked with a number of large clients and this exists everywhere. So how do you define technical debt?
00:08:53 - 00:09:41
Amarjeet
So just extending more to what Matt shared. So I think it's just about a accumulation of imperfection in the technical environment. However, it's important to understand the sources or scenarios that is leading to technical debt. So largely if you ask me, I would like to break it down into 3 specific scenarios. One is deliberate or intentional, the other one could be inadvertent or unintentional. And lastly it is environmental technical debt. So what these 3 means, let's expand it more about these 3 scenarios so that we can relate in terms of what is known and control level versus what is not, and can surprise without giving any warning any point of time.
00:09:42 - 00:10:33
Amarjeet
So starting with deliberate or intentional debt, it is a scenario wherein the team takes a conscious decision or call to knowingly go about continuing taking that route. It could be because of multiple scenarios. For example, Matt talked about there's a request from the business to launch a new feature possibly in the market in a shorter time spent because of competitive advantage or you want to launch a new minimal viable product to understand the market potential. So all these scenarios can lead to a cut short some of these standard practices, like architecture design or coding practices, which may lead to some code smells, stale code, or leaking some bugs in production due to minimal testing and so-and-so forth. So this is the first scenario.
00:10:34 - 00:11:22
Amarjeet
The second scenario, which is inadvertent or unintentional tech debt. Now this is something which is a cause of concern because this scenario is wherein bad code enters into technical data environment without being caught, and this can lead to multiple impacts, maybe frequent disruptions you're seeing in production or there are performance issues, or the cost of maintenance is getting higher. Now this could be again because of multiple factors, for example, the team experience who build that product or adherence to technical governance, process governance, insufficiency of tools that Matt talked about. If we are not using the right tool, this can lead to some of these issues getting into production.
00:11:23 - 00:11:57
Amarjeet
And lastly it could be because of testing maturity even. So this is unintentional, this is one category that needs to be really taken care of. And finally the last category is environment technical debt. Now this is interesting wherein initially everything was hunky-dory, everything was fine, there wasn't any technical debt. But however, over a period of time the technology changes, the landscape changes, the infrastructure is depreciating, and suddenly we'll start seeing the debt start accumulating in the environment.
00:11:58 - 00:12:42
Amarjeet
Some examples could be like Matt was talking about patching. So if patches are missed and get accumulated, that means it is a debt that is getting cured over a period of time, or the functions that are getting depreciated, or the infrastructure is getting outdated due to maybe environment getting changed, and the operating system getting changed and so-and-so forth. While the first category that is intentional is largely under the radar, and [inaudible 00:12:32] part of the product development cycle. The second and third categories are generally missed and tracked until the resurface as a significant issue and start impacting the business.
00:12:43 - 00:13:24
Amarjeet
So if I have to sum it up, tech debt is a cost, no doubt about it. However, some of the tech debt, like intentional tech debt can be beneficial as long as it gives a jumpstart to achieve the overall goals that the organization is looking forward to and the benefit outweighs the correction cost. However, unintentional and environmental tech debt needs to be averted at the first instance. And if it still slips, then let's keep identifying all the time and systematically addressing it to wide surprises. That's my point of view, Jen.
00:13:25 - 00:13:54
Jen
Well, definitely I've heard there's multiple types of technical debt, multiple categories, so how an organization defines that and classifies it, I think just being able to do that is helpful to have common terminology in an organization. And certainly we've all seen where upgrades get missed and first it's one and then it's 2, and then 5 years later you have a product that can't be supported anymore by a vendor. So understand it does creep in.
[Presentation slide 3. Slide title is "Technical debt—cause and impact." A statement below the slide title is a direct quote, "... technical debt hinders productivity, delays turnaround times, and strains resources, all of which directly impact the total cost of ownership and, in turn, a business's bottom line." Below this direct quote reads “Quote from CAI’s white paper “Unlocking the secrets to managing technical debt.”" In the center portion of the slide, there is a series of statistics related to technical debt, each accompanied by an icon. They include: "78% of organizations have accrued more technical debt in the past year than in previous years" below to a calendar icon: "58% of organizations lacked an official strategy to tackle this debt" below a lightning bolt icon: "23% of developers working time wasted due to technical debt" below a checkmark icon: "52% of 1,000 developers report spending 17 hours a week debugging and refactoring code" below a magnifying glass icon: "76% of 1,000 developers reported a negative impact on morale due to technical debt" below a thought bubble icon. The bottom of the slide has the CAI logo and the slogan "We power the possible." The name "Jen Boyer" appears in the top right corner of the slide, alongside a photo of a talking head, indicating the speaker.]
00:13:55 - 00:14:47
Jen
All right, well let's move on now to how we identify and measure technical debt. Sources, depending on what you read, we'll say anywhere from 56 to 70% of CIOs or technical executives will say that technical debt is a leading obstacle to innovation and a source of wasted IT budget. I've seen some tech leaders get very analytical about this where they go through everything to identify technical debt, and they apply weighted measures to it based on risk or cost to service or impact, and they have a detailed plan. And then I've seen the other side where especially when somebody new comes into an organization, they can see some of the symptoms but they have no idea where it is or how to identify it and how to measure it.
00:14:48 - 00:14:56
Jen
So Amar, how have you seen clients go through the process of identifying and measuring technical debt?
00:14:57 - 00:15:26
Amarjeet
Yeah Jen, so I'll take a step back. So the past 4 years we have seen an increase in technical debt, specifically during and after pandemic phase as a lot of organization were undergoing significant shift to digital platform, and they were changing the ways of working. In addition, there are new technologies that are coming across which are also contributing change in the ways of working, the business practices, and so on and so forth.
00:15:27 - 00:16:04
Amarjeet
So almost 78% of our organization have accrued more technical debt in past years, and this is also straining and impacting the developer's morale as they must constantly address the growing technical debt along with really enhancing the current platform. And according to IDC, more than 500 million application and services will be developed starting 2023, which is the same number of applications that got developed in the last 40 years combined.
00:16:05 - 00:16:41
Amarjeet
So this is a massive change, massive, massive change. And with this massive change and the shift in business priorities, I bet technical debt is not going to go away, it is going to continue accumulating, and this is not going to make the life easier for CIOs or CXOs. So how can the situation be checked and managed? There are multiple ways to approach it, and it's not that the first approach, the second approach is right, but there are multiple ways to go about it and it all depends upon the information that is there with the team.
00:16:42 - 00:17:21
Amarjeet
So first and foremost is, identify the critical and high impact business. So what I mean by that is, examine the current landscape of the business in terms of the supporting technology that is there, the infrastructure and the future growth readiness is there from that current platform. So what are the different questions that you can look forward to be answered? Is the current environment that we have is capable of maintaining the current and future business growth? If not, what steps can be systematically taken to be relevant, not only now but in future as well?
00:17:22 - 00:18:14
Amarjeet
And secondly, we need to really see that when and what is the right time to initiate those steps because that is going to be important. If any step is being delayed, that means that's going to be creating a problem in future as well. So do that, create a plan. It's always important to create plan and get the budget, because the most important aspect is getting a budget. If there are delays in getting budget, you will miss the bus. So that's one approach. If that is not viable and everything is important, then maybe we can shift the paradigm altogether. If everything is critical, then you may want to look at and change the strategy by measuring the platform stability and adaptability. What does it mean that? Or what kind of questions that you can ask.
00:18:15 - 00:18:59
Amarjeet
You can look at what is the current cost of my operations, is it too high and continue to remain higher, and is also increasing year-on-year? That means there is some issue out there. Are there frequent failures, outages or vulnerabilities that is visible in the current landscape? How easy it is to scale up? Because business always wants to scale up. Something new comes up, it needs to be implemented. So how easy it to scale up and implement the new business requirements. The most important aspect is, and that is a leading indicator whether you're running into any challenge, is the team getting fatigued?
00:19:00 - 00:19:48
Amarjeet
Because their job is not only to keep the existing platform up and running, but they also need to keep pace with the changing business environment by adding new features which business is pushing to them. If the system is unstable, then the team will be spending most of their time fixing issues rather than adding any value to the platform. Other thing could be, an indicator could be from the customer, is there a drop in user satisfaction? So you can also assess the current technology landscape, and from the perspective that it has the ability to innovate and adopt the scenarios, is the current technology relevant for the current and future requirements?
00:19:49 - 00:20:16
Amarjeet
Lastly, skills availability. I think it is important from the perspective that am I getting, is there a continuity I'm getting availability of skills to keep the platform running? If not, I think I need to really see that it's a technology that is changing and probably I'm not keeping a pace with the technology as well. So these are some of the indicators, Jen, that can be looked at to measure technical debt and identify that.
00:20:17 - 00:20:39
Jen
Okay, good. Yeah, all good questions that you can ask if you don't know where it is, there's a lot of questions in there that you can certainly start asking the team, yourself, and things like team fatigue or skills availability, those are human being related perspectives, but they matter just as much. So good points.
00:20:40 - 00:20:49
Jen
Matt, what have you found is the most important measures or indicators around technical debt in your role?
[The presentation closes and there are three boxes on the screen, each containing a name and a speaking head. Jen Boyer’s name and talking head appears on the top left: Matt Peters’ name and talking head appears on the top right: Amarjeet Singh’s name and talking head appears directly below them in the center of the screen.]
00:20:50 - 00:21:31
Matt
For us we've really found that measuring time on task is really one of the best indicators that we can hope for to identify technical debt. And that works in a few different ways. So for us, if we're seeing that we categorize time based on new development or maintenance for any platform that we support, if maintenance time is increasing over time it's usually a good early indicator that technical debt is present and it's starting to grow. If we're on the development side of the house, we're looking at how many user stories can we fit into a sprint on average for a given application. If that number is going down over time, it's another indicator that technical debt is probably present and worth investigating.
00:21:32 - 00:22:11
Matt
We really try to focus pretty heavily on those because they are leading indicators of the presence of technical debt, and they help us, not necessarily identify the debt itself, but they help focus our investigative efforts so that we are going after the right areas to find technical debt as quickly as we can and we're able to address it obviously as quickly as we can. I like time on task because in both of those, whether it's build or maintain, in both of those cases there's a very strong correlation between changes in those measurements in the presence of technical debt, irrespective of other variables that we normally worry about, like what's the platform, what's the language that you're using?
00:22:12 - 00:22:51
Matt
Other factors that certainly bring a nuanced component to how you look for and how you address technical debt, but time on tasks sort of works universally across everything no matter how you're doing it. That said, for it to work for you, you have to have a reliable baseline that you can start to operate from so you really know if numbers are going up or down. And for a lot of organizations it can be a pretty substantial change to how they manage to actually capture and categorize time in the ways that I'm describing. But for an organization that can pull it off, it's very powerful and it gives you a really, really good channel to identifying, and also to prioritizing the technical debt that you have in place that is worthy of being addressed.
00:22:52 - 00:23:41
Matt
And I like it in particular because it's the earliest symptom that we can see of it. So we're not over emphasizing technical debt that might be found in some kind of an automated discovery and may ultimately introduce no real pain into the organization, and therefore not be debt that we have to address right now and we can afford to carry for a little while. When you look at time on task shift, that really means that you're hitting something that is at the very beginning of having an impact on you or your organization and it feels like the right time to deal with it. And it's not the only way that we do it, we do like to evaluate a variety of code metrics, code duplication, churn, things like that. Those do give us good avenues to help introduce automation in a useful way in managing and identifying some technical debt.
00:23:42 - 00:24:32
Matt
And we also, I mean the point was made earlier, some of these are just people issues or people problems. We listen to our developers, that's a lagging indicator, not a leading indicator, but we know that developer morale and retention is strongly correlated to the presence and the pain of technical debt. And so we do really like to look at what's our retention look like, are we seeing any kind of numbers shift there in any meaningful way? And even if it's not, we touch base with our developers a lot about just where they're at, what they're struggling with. Fortunately for us, our retention numbers are very good and it suggests that our technical debt overall as an organization is either low or well managed, but I think those are pretty powerful indicators for an organization that really wants to take this on and take it seriously.
00:24:33 - 00:24:59
Jen
Okay, great. I know we're pretty fanatical about time management and timekeeping and it works great for our organization, but that can be a real culture shift for other organizations, salaried employees, tracking time, not tracking it to see if people are working, in fact you're tracking it for other reasons, like indicators of technical debt. So that's a great point.
00:25:00 - 00:25:36
Jen
Back to you, Matt, a couple of questions. Funding technical debt projects or efforts to go after it can be really hard. There's the analogy of the Golden Gate Bridge, as soon as I'm done painting it, I need to start painting, I need $15 million to start painting it again. So this is a two-part question. How do you put that business case together, and then can you give us a real-world example of where solving technical debt had a really positive outcome on the business?
00:25:37 - 00:26:14
Matt
I think I mentioned earlier one of the most important tools that we have in addressing technical debt in our organization is really just expectation management. So we tend to know, and I think a lot of organizations can know, depending on your development methodology and the objective that you're working against, you could very intentionally be accruing a good bit of technical debt for all the right reasons. But as a product owner or an individual responsible for the product to be released, I'd say you can't stop talking about that with the rest of the business.
00:26:15 - 00:26:58
Matt
As soon as it becomes something that's behind the curtain, the expectation for what needs to be paid for and what's important and what's not starts to shift in the minds of a lot of other business stakeholders. So upfront communication is just, it's a really important way to stay out in front of it. Beyond that, when addressing technical debt becomes more of a larger scale project than part of a product development lifecycle, we usually rely on the technical debt ratio, it's not something we invented, we simply borrow, but it's a quantitative comparison between the cost of fixing the debt and the cost of rebuilding or redeploying as an alternative to actually addressing debt inside of any application that you have to manage.
00:26:59 - 00:27:36
Matt
So we really just look at that and say, "Well the higher the ratio, the higher the presence or the level of technical debt that we need to address." And as long as we're experiencing some kind of symptom or pain there, we use that as the mechanism to say, "This allows us to quantify the presence of it, to size the effort to address it. It allows us to draw some kind of a linear connection to pain that we're experiencing in the org." And again, all 3 of those things are really just quantifiable ways to do what I said at the top, which was set the expectation and keep talking about the presence of debt on an ongoing basis.
00:27:37 - 00:28:23
Matt
I think for most organizations, and us included, it becomes most painful shortly after you stop talking about it, and so don't stop. And that said, within CAI, I wish I could tell you that we have no debt, but that's simply not the case. I think we do a pretty good job of only incurring the debt that we want or that we can justify. But a good bit of it, as I mentioned earlier, is sort of forced on us by our clients, and there are lots of examples where we've been able to address that. But I mean we've gotten into engagements with clients. Actually, we're working our way through one right now where they've deployed significant legacy systems that run some very complicated back office functions for the organization.
00:28:24 - 00:29:09
Matt
The idea of re-platforming for where they're at as a business right now is simply unthinkable. We understand that as a company, we're not trying to force them into any direction that they can't go, but it does mean that we need, CAI needs to be able to support workers on very, very old operating systems that can't even be security patched anymore, that we have to be able to connect to legacy platforms that have a lot of vulnerabilities, and we have an obligation to all of our customers that all CAI infrastructure assets, et cetera, are all secured, and all actually conform to a wide variety of elaborate security standards because we service all parts of private industry and the government. So we have a lot of things that we have to be able to say yes to from a security front.
00:29:10 - 00:29:53
Matt
So when we get into technical debt situations like that, again, it's something that we identify from the front with the customer. We're always talking about the fact that it's present, it needs to be dealt with and it's going to come with some costs. But we've been able to actually, we were the only vendor in play in this particular case where we had a strategy for managing and mitigating the technical debt, where all other vendors that the company had an option to go with would've had to force some level of re-platforming on them in order to be able to get to a deliverable outcome, we were able to say, "Well, we can actually do a lot with network segmentation and virtual machines to give you duplicated environments that your folks can get into that still keep us secure."
00:29:54 - 00:30:35
Matt
It was a big undertaking that on the surface didn't actually provide any value to the customer or to CAI, if you're not looking at it through the lens of the technical debt ratio and really characterizing the work that needs to be done in the context of, how present and painful is the debt, how much security vulnerability does it open us to, and therefore how much choice do we really have? But the answer is always some, there's never only one way to deal with technical debt. I think what we tend to do a good job of and that I'm very proud of is that we find novel ways to make it more painless when we cannot eliminate it. And that's actually been a point of focus of ours for quite some time.
00:30:36 - 00:31:03
Jen
I actually have a case where CAI is doing an asset upgrade, some upgrades, and we have a client that we need to support with the legacy operating system that we can't do the upgrade. So I agree with you, we're working through that to find a way to be able to still support the client's environment and meet our own internal needs. So appreciate those insights.
[Presentation slide 4. Slide title is "Managing technical debt." A quote from CAI's white paper "Unlocking the secrets to managing technical debt" is featured which reads: “…it’s important to include technical debt in every conversation…This includes conversations about strategy, planning, hiring, and more…” The slide is divided into two sections: "Software development cycle" and "Operations," each with a bullet-point list. The Software development cycle includes: "Bake technical debt into the software development lifecycle," "Audit existing tools and systems," "Create a roadmap and timeline of actionable plans." Operations list includes: "Take stock of existing technical debt," "Audit existing tools and systems," "Plan for any known technical debt that will occur as a result of a project," "Find balance between paying off existing debt and incurring new." The CAI logo and tagline "We power the possible” is found at the bottom of the slide. The name "Jen Boyer" appears in the top right corner of the slide, alongside a photo of a talking head, indicating the speaker.]
00:31:04 - 00:32:02
Jen
All right, well let's talk about managing and resolving. It's great if you can do it, but it sounds like there's always going to be some level of technical debt in the organization, and it really comes down to, what are the strategies you could use to manage it. I've seen where resolving technical debt has been a real game changer for CIOs, especially as they're trying to have those conversations about innovation and strategic projects, but it doesn't go anywhere if the operation itself is having frequent outages or the cost of maintenance is too high. So resolving it frees up the mind space and the conversation to look at and focus on the future. In some cases I've seen where it's built into the lifecycle that a percentage of capacity for every sprint or every release is dedicated to technical debt.
00:32:03 - 00:32:17
Jen
So Matt, in today's AI and hyper automation focused world, as you're looking at strategies to address technical debt in the organization, how are you leveraging AI to do that?
00:32:18 - 00:32:52
Matt
Admittedly, I don't get out of any conversation without talking about AI, and this is no exception. But it is actually, it's an interesting place where AI has some meaningful impacts. So we as an organization, we've been leaning very hard on generative AI solutions. They're being deployed to a lot of different use cases across the organization. With respect to technical debt, we're actually able to see some pretty significant gains from using AI, not necessarily to eliminate technical debt, but to reduce its introduction, and also to make managing and identifying it cheaper.
00:32:53 - 00:33:29
Matt
So if you think about generative AI, as a technology it's very good at interpreting intent of a user, which translates directly to being able to correctly interpret intent of code. So getting AI solutions can actually do a pretty good job of doing code review to identify any kind of waste, any kind of duplication, other good indicators of technical debt. But it doesn't force us to build a bespoke solution for every language or every platform or every compiler that we work in. The GenAI solution can just be turned loose without a whole lot of contextual background, given the way that we've configured it.
00:33:30 - 00:34:21
Matt
So it allows us to introduce it into a lot of code review cycles. We use it to create new code, and by using it in that way it brings a certain level of uniformity across all of our developers. That code is being introduced in a consistent fashion that reduces a lot of our risk of introducing new technical debt. We also use it to review a lot of legacy code that we're ultimately working on. And in that context it does a pretty good job of pointing out areas where we either have the traditional markers of technical debt, like code duplication, that sort of thing, but also inefficiencies. It does a good job of identifying API calls that make a long series of individualized requests instead of being able to bundle and pass one full request through at once. So it even finds opportunities for us to make code that isn't painful yet more efficient.
00:34:22 - 00:35:13
Matt
So we like it in both of those cases, and we use it across the organization pretty aggressively. I'd say the other thing that it really allows us to do is, because it makes it cheaper for us to find and identify and create a mitigation strategy for a lot of that technical debt, it gives us the opportunity to go after smaller, more nuanced examples that aren't really painful yet, but arguably the earlier you address any kind of technical debt, the more you manage the interest that you're paying on it. And so being able to be a little bit more opportunistic, because, "Hey, the AI found it, it's cheap and quick and easy for us to get it fixed, we might as well just do it even though it doesn't hurt yet." That over time, that's just bringing the overall presence and the overall technical debt ratio for the organization down in a pretty positive way for us.
00:35:14 - 00:36:04
Matt
So we're pretty bullish, all things considered, on the role that gen AI can have in development and in particular in the context of managing technical debt for the organization. It gives us a good mechanism to be able to have an approach that is reasonable from a labor intensity and a costing standpoint, but also lets us take off a lot of small debt scenarios instead of waiting for big debt events. And that effectively is the same as protecting yourself from the death by a thousand cuts outcomes that a lot of organizations see from technical debt. It's not often one big debt that you owe, it's many, many small ones that are impossible to gather and deal with. I believe GenAI is helping us with that a lot.
00:36:05 - 00:36:13
Jen
Awesome. Well, that's a great example. I always get questions, "How are you using AI? What are effective use cases?" And this is a great one.
00:36:14 - 00:36:34
Jen
So Amar, how do you see debt being monitored, managed, or even resolved in the software development lifecycle? I know you work with many of them. And just from a quick time check, we have about 5 minutes, and then I saw some questions come in, so we'll move to Q and A.
00:36:25 - 00:37:23
Amarjeet
So Jen, I agree with Matt what he talked about. The only thing is I'll just add a few more aspects to it. The product quality is directly related to the ease of maintenance. So thereby if it is addressed upfront rather than leaving it in the later part of the product lifecycle, it's easier and cheaper to address that right away. So that's why baking the open technical debts that are identified during development cycle and managing them as part of retro fix in the development cycle is easier. So it's all about simplification, keeping the basic principles in place. Everything is revolving around 4 key principles, people, process, tools and governance.
00:37:24 - 00:38:12
Amarjeet
Now resource is the core of any development. So getting the right skill team is essential specifically when following the agile process because it is individual who are the key to develop that particular piece of code. So while getting right resources, one job done. However, onboarding these resources is equally important in getting an understanding and adopting the current processes that have been defined, including the enterprise architecture, coding guidelines, and so-and-so forth. So it's important and vital to eliminate unintentional or inadvertent technical debt through onboarding process.
00:38:13 - 00:39:09
Amarjeet
The second thing is related to defining the process and guidelines in terms of the standards that they need to follow, so that everybody's following the common standards of how to go about coding it, and adhering to that so that it's easy to maintain in future. Third thing is toolset. So adopting the right toolset, including new generation technologies that Matt talked about. So it is important to adapt the right toolset to check code quality, detect bugs early in the lifecycle, and reduce code smells. So this is important. In addition to that, testing is important. So automation testing tool to check the requirement compliance, traceability, test coverage, and so on and so forth could be another aspect. And it is important to have deployment through continuous integration and testing process.
00:39:10 - 00:40:09
Amarjeet
So once that is done, it also helps eliminating some of these things later part of the time. And lastly, it is all about governance, including the architecture compliance, governance, code review governance, program governance. And equally important is tracking and addressing the open tech debt issues, and creating a refactoring cycles as part of sprints to address that so that it is not being pushed to the later half of product lifecycle into operations. So finally, it is also important to do retrospect and share the lessons learned across the team so that it is not repeated in future. So I believe if these principles can be adhered, very simple principles as part of development lifecycle, probably there is a high chance of leaving a less number of technical debts in the future part of product cycle.
00:40:10 - 00:40:37
Jen
Okay, great. No, I appreciate that. And you bring up a good point that onboarding new resources can be a point where technical debt makes its way in. Everybody comes with their own standards and habits, and so making sure that everyone in the organization when they onboard understand what the practices are, what the definition is, and how do we manage technical debt as part of the software development lifecycle is a very good point.
00:40:38 - 00:41:01
Jen
So I know we've talked about a few strategies with regard to the software development process, and automation and AI in terms of avoiding. Any other best practices, Amar, that you could recommend for avoiding technical debt? Maybe we already covered it, I mean I know it's utopia, right?
[The presentation closes and there are three boxes on the screen, each containing a name and a speaking head. Jen Boyer’s name and talking head appears on the top left: Matt Peters’ name and talking head appears on the top right: Amarjeet Singh’s name and talking head appears directly below them in the center of the screen.]
00:41:02 - 00:41:43
Amarjeet
Yeah, we had covered it. I think let's bring it to another part, which is once it move into operations. So technical debt, there would still be some debt which is unavailable, maybe for various circumstances, and that creeps in knowingly. That is intentional. Knowingly it is going into the operations. So it's important to keep the product in check. So document the carry forwarded from a development cycle, keep continuing monitoring and tracking technical debt, because you're going to be adding new features irrespective, and there could be environmental changes that is still going to be happening.
00:41:44 - 00:42:27
Amarjeet
So keeping a check of that is going to be important. Maintain a risk register, keep monitoring, tracking, prioritizing the open technical debt. It is important not to let it go out of sight. That's the key out there, because that is wherein most of the organization gets into a rabbit hole wherein they do not keep track, and suddenly you start seeing that some of the issues start becoming a problem to handle at a later point of time. So keep that monitoring, keep auditing your tools, existing tools and system. That is important. Because similar time they may not be relevant anymore in the current environment or current landscape. So that needs to be done.
00:42:28 - 00:43:16
Amarjeet
And keep highlighting significant issue to be prioritized with the business, with the stakeholders, get the appropriate budget and address before it becomes considerable business impact scenario. And finally, it is important to keep the software currency updated, the patching part. So some of the organization has got strategies around keeping it in minus one rather than keeping it in for some reasons. But whatever strategy that organization adopts, it is important to keep that strategy in place and make sure that the software currency is up-to-date. So these practices allow technical debt to be controlled during maintenance cycle, and you can make your product more accessible to maintain and update in the long run.
00:43:17 - 00:43:54
Jen
Okay, good. Well, at this point we're out of time. We're going to move to the audience Q and A. So thank you for your insights, it's been a great discussion. We've heard that technical debt is going to exist in one way or another in an organization. So it sounds like the best recommendation is to figure out how it exists in your organization to build that strategy to manage it. So just to summarize, we talked about really 4 key areas define, and what I heard was there's multiple categories.
[Presentation slide 5. Slide title is "Minimize technical debt by activating this 4-step strategy.” Below the title, the slide outlines the 4-step strategy, presented as a numbered list within colored squares. The steps are: "1. Define" in a dark blue square: "2. Identify and measure" in a lighter blue square: "3. Resolve" in an even lighter blue square: "4. Avoid" in a green square. The bottom of the slide encourages visiting a link "To learn more, visit www.cai.io/adm360-event" The CAI logo and tagline "We power the possible” is found at the bottom of the slide. The name "Jen Boyer" appears in the top right corner of the slide, alongside a photo of a talking head, indicating the speaker.]
00:43:55 - 00:44:33
Jen
So however you define it in your organization, make sure that everyone knows whether they're existing employees or to your point, Amar, there are people that are joining the organization. Identification and measurement. Amar, you gave us a number of questions that we could ask in terms of identifying it. So is the system stable? Are there frequent outages? How does the team feel? Matt, you talked about leading indicator of time on task. Are people spending more time in a particular area, and that's a great indicator that debt might exist?
00:44:34 - 00:45:14
Jen
We talked about different ways to resolve and how AI and automation can really help with either resolution or managing technical debt, even avoiding it going forward. So all great points. Appreciate your insight. We will move over to questions. If anyone needs any more information on the webinar today, feel free to visit us at the link. There's a link on the slide. I believe they'll put it in the chat as well. You can visit that link and pose any additional questions that you may have, or if you want some more detailed information on a particular topic, you can find it there.
[Presentation slide 6. Slide is gradient light blue in color. In the center of the screen in larger text reads “Audience Q&A.” The CAI logo and tagline "We power the possible” is found at the bottom of the slide. The name "Jen Boyer" appears in the top right corner of the slide, alongside a photo of a talking head, indicating the speaker.]
00:45:15 - 00:45:37
Jen
So from a question and answer perspective, let me pose the first question to Matt. Cloud is everywhere. Is there any technical debt associated with being on one cloud provider versus a multi-cloud strategy?
00:45:38 - 00:46:22
Matt
I would say in the context of a causal relationship, like one strategy versus another, forces more technical debt on an organization. I don't think that's the case, but I would say that a single cloud provider versus a multi-cloud strategy, it does change the way that an organization is able to address technical debt. It drives a little bit of what kind of options you ultimately have. If you think about it in the context of an organization with a single cloud provider, you're basically, as an organization, you're beholden to their release and enhancement schedule as they introduce new functionality that allows you to change the way that you're working and address some technical debt.
00:46:23 - 00:47:02
Matt
You're probably on a path to a reasonably low cost of ownership in addressing technical debt overall, but you are also probably on a slower road to actually having the opportunity to deal with debt as you identify it. So I'd say there's a little bit of a mixed bag there. On the flip side though, with a hybrid or a multi-cloud environment, that probably means that you have more options to move more quickly in order to address debt as you identify it. Different platforms have different attributes and different shortcomings. So if you can move delivery or capabilities around you, you have a wider variety of tools at your disposal to be able to address any technical debt.
00:47:03 - 00:47:42
Matt
But at the same time, you're now operating in an environment where multiple vendors who are not necessarily aware of or care about each other's release schedules are pushing updates into environments that you're managing. And so the unintended introduction of any kind of debt or a change in the variable that makes known debt more painful, you're at greater risk of experiencing that on a more aggressive cadence. So I wouldn't necessarily say one is better or worse than the other in terms of technical debt, but your strategy will drive how you are able to some degree to address technical debt.
00:47:43 - 00:47:53
Jen
Yeah, a good point, "Somebody makes a change over here, but I'm dependent over here, and now things aren't working as expected." So a very good point.
00:47:54 - 00:48:05
Jen
All right, our next question, let's go to you, Amar, this time. How have you seen technical debt impact business users and/or customers, and customers?
00:48:06 - 00:49:11
Amarjeet
So I came across a few instances while managing some of the engagements. However, let me share one instance which was unanticipated and turned out to be an inadvertent debt that went under rugs unnoticed possibly, and created a business situation over time. So one of our clients had a security scare wherein which led to the security team define a new policy and require all passwords to be changed according to the new set of guidelines, including minimum of trail correctors, a combination of other factors, blah, blah, blah, all those stuff, while it appeared to be a simple task to go and reset the password. Because generally the passwords are either stored in database or configuration files. However, while the team was trying to do that, they resurfaced that the running application post password change started throwing errors and exceptions.
00:49:12 - 00:50:15
Amarjeet
And when they start looking into that, it appeared to be a simple change. But this task, a easy task turned out to be a nightmare. The reason being is that it was hard coded, and to figure it out it took enormous time, and the budget that we really planned out to address this issue went on to multifold since additional task now was supposed to be done, not only to identify the static code where it is, but also to convert into a generic functionality and fix the debt. So you can imagine that this missing generic code practice is a very simple stuff. We should not be hard coding passwords in the code. So it is a very generic code practice which could have been taken care of during the development cycle, however it turned out into a substantial exercise with not only adding the cost but also compromising the security for that duration.
00:50:16 - 00:50:31
Jen
Yeah, it's a significant case, we've all seen where something seems like a simple change and then it blows up into a very expensive, much longer than expected change. So that's a great example.
00:50:32 - 00:50:46
Jen
Amar, looking at it from a different angle, what are some examples of good technical debt that you've seen taken on during the development of new products, is there such a thing?
00:50:47 - 00:51:39
Amarjeet
Yeah, I can give you a couple of examples out there, Jen. First and foremost, I think good practices follow keeping simple coding principles. I can give you one example from that perspective. Like say supposedly you have a static page that needs to be coming down once in a year or twice in a year. Now it is simple that you create a static page out there and implement that for that duration that it is needed. It is twice a year, rather than if you complicate things, you go and create a CMS. Once you create a CMS, that means it has got additional functionality that is there, additional system that needs to be there which needs to be maintained, additional functionality. The outcome is pretty minimal.
00:51:40 - 00:52:07
Amarjeet
So thereby I think it is a technical debt if you do not go to CMS, but I think it is to be weighed around whether it is important to really go and create a CMS system now with the kind of usage that is there, it is not needed. If it comes across that I need to do this exercise every month or twice a month, it makes sense to create a CMS system, but not at this moment. So it is a good technical debt to start with.
00:52:08 - 00:52:58
Amarjeet
The other thing that I can think of is throw-away code, and this is one of the terminology that is being used for experimentation, it is always worthwhile experimenting things on smaller codes to see and test the feature, rather than building up the entire feature, which is a huge complex feature, and thereby you learn after you have completed it, and it takes enormous time to really correct that. So throw-away code is a good technical debt to start with wherein you work on that, you get feedback, and then expand it further on that. So these are 2 examples I can talk about from a good technical debt perspective.
00:52:59 - 00:53:21
Jen
Okay, good. Appreciate that. It looks like we only have time for one question. So I think, Matt, I'll go to you for this one. When should organizations, or frankly CAI guess, prioritize addressing technical debt and how can they strike a balance between new development and debt reduction?
00:53:22 - 00:54:05
Matt
I'd say the oversimplified way to answer that is it should be easy to prioritize it when it begins to hurt. So be attentive to the pain that debt can cause, but that is admittedly an oversimplified answer. I think one of the good ways that organizations can get a handle on technical debt, this kind of builds on a MaRS example of some good examples of debt. If you use a minimum viable product approach, an MVP approach like we do, a lot of the time you'll find that we might be taking a product down a development path that says, "We know we want desktop and mobile for this application. We'll build out initial elements of both."
00:54:06 - 00:54:44
Matt
But once we roll that MVP out to a user base, and we've done this before and seen that almost no one actually used the mobile app whatsoever. We were dealing with financials and a mobile app isn't a good way to consume those. We anticipated a lot from the user community but didn't have them. So we were able to cut off an entire development arm of the overall product that we were trying to build against, and that actually created availability that we could then say, "Well, it's easy to come back now and justify that we need to build around more refined and more mature code around the capabilities that we are delivering on the desktop, and we put all of our emphasis there."
00:54:45 - 00:55:16
Matt
I think for a lot of MVPs, most organizations will really try to get to a multimodal delivery model and not all modes will be necessary. So if you're budgeting for more than you're ultimately going to build, then when you recover a little bit of that budget, if you jettison something, now is the time to fix that technical debt. Because it's the moment where you have the resources where everyone's familiar, where the cost is still allocated and you can address debt before you pay a ton of interest on it. I think that's a really healthy way to think about it.
00:55:17 - 00:55:50
Jen
Yeah, a good point. I mean, I like what I heard today, "If it's out of sight, don't let it get out of sight. Don't let it come out of the conversation." What was the other point? "Out of sight, out of conversation, or if it falls out of the SDLC, all of a sudden it's growing somewhere and you're not able to necessarily address it." But your point's well taken, Matt, that when everybody's focused on this particular project, now is a good time if you have the capacity and the availability to address that technical debt.
00:55:51 - 00:56:40
Jen
Okay, well it looks like our time is up for today. It's been a pleasure chatting with you both, appreciate your insights and informative discussion on this topic. Thank you very much. A big thank you to all of you who have attended today. It's your attendance, your questions, your interests that makes these webinars very successful. We hope you'll take away 3 key lessons from today, how to define and classify technical debt in your organization, when to look at AI or automation as a possible alternative to address it. Some ways that you could build it into your SDLC, and ways to position technical debt with the business to get the funding and support that you need to address it.
[Presentation slide 7. Slide features the CAI logo and slogan "We power the possible” on the top left. The text below "Webinar. Maximize the potential of your applications and minimize technical debt" is displayed. Below this text reads “Thank you for attending! To learn more, visit www.cai.io/adm360-event” The background image shows a man in an office environment working on a monitor, with graphs, codes, and data displayed all around him. The name "Jen Boyer" appears in the top right corner of the slide, alongside a photo of a talking head, indicating the speaker.]
00:56:41 - 00:57:35
Jen
So in the coming days, we will be sending out a replay of this webinar along with some additional links for resources and things that you can look at to continue your learning. Feel free to share it out with your colleagues. Don't forget to check our upcoming webinar schedule, we do have a number of them this year focused around application management best practices, as well as automation and hyper automation. In the meantime, if you are interested in getting specific information or questions answered, feel free to visit the link on the website, cai.io, our website /ADM360-event. You can pose any specific questions there or ask for materials and resources, as well as feel free to reach out to any of us via LinkedIn directly.
00:57:36 - 00:57:48
Jen
So, thank you again, and hope everyone has a great day.
[Closing slide 1. Blue CAI company logo with tagline “We power the possible” appears in middle of screen. Company website www.cai.io appears at the bottom center of the screen]
[{"asset_name":"www.cai.io","asset_url":"https:\/\/www.cai.io","asset_type_code":"site"},{"asset_name":"Resources","asset_url":"https:\/\/www.cai.io\/resources","asset_type_code":"page_redirect"},{"asset_name":"Events and Webinars","asset_url":"https:\/\/www.cai.io\/resources\/events-and-webinars","asset_type_code":"page_standard"},{"asset_name":"Maximize the potential of your applications and minimize technical debt","asset_url":"https:\/\/www.cai.io\/resources\/events-and-webinars\/minimize-technical-debt","asset_type_code":"calendar_event_single"}]
Unleash your apps' potential and shrink your tech debt. Watch this on-demand webinar and learn from 3 subject matter experts who shared strategies to modernize and rationalize your applications to remain competitive, improve user experience, and pay down technical debt. If your company is interested in working with CAI, contact us today.
