Why Software Maintenance Is Stuck in 2015 ![rw-book-cover](https://img.youtube.com/vi/gMn6JkLDaGc/maxresdefault.jpg) Hi everybody. Uh a huge thank you today for joining us for this discussion on why software maintenance is stuck in 2015. And this is a lead dev online panel discussion created in partnership with draft. The discussion today is going to last approximately about 45 minutes after which both myself and the panelists are going to head over to the lead dev Slack. Um we'll be answering some of your questions there if you've got them in the um panel Q&A channel. And if you haven't already joined the lead dev Slack, you can do so by going to leaddev.com/join slack. We will also hopefully have time to answer some of the questions either as the panelists are going through and I can work them in um or at the end. So if you do have anything that you want to ask us then feel free to submit them um through the uh the Q&A feature on Zoom um and I'll get to them like I say whenever we can. Um but first we're going to get started with just a few basic introductions. My name is Sally Le. Uh my pronouns are she and her and I'm a fractional technology leader and adviser based in the UK and I'm joined by four incredible panelists today. I'm really excited um that they're here with us. They're going to be sharing their experiences, sharing their insights and I'm going to let them all introduce themselves starting with AB. So Abby, could you tell us a bit about you and a bit about why you are particularly excited about being here and this topic? All right, no worries. Thanks Sally. Um hi everyone. and I'm AB. I'm currently the CTO and co-founder at everyone calls us Metri Fox or Foxes, whichever one you prefer. It's a monetization platform for AI agents and SAS companies. Before Metro, I worked as a software engineer on multiple core teams and a developer experience team as well as an EM at places like Factorial and Clue. having been on both sides of the aisle, being someone who had to maintain painful code bases as an IC and also someone then being the person later responsible for setting good standards and trying to convince the business to invest in them. I would say that I bring a holistic view to the topic of software maintenance and yes, I'm really excited that we are discussing it. >> Oh, thank you. I'm so glad that you're here with us today. And next, I'm just going to go over to Hila. So Hila, could you tell us a bit again about yourself, your background and why you're particularly excited to be here today? >> Sure. So I'm Hila Fish. I'm currently a solutions architect in AWS and beforehand I was a DevOps engineer. So I'm looking at this uh particular topic from both ends. So as a devops engineers help as devops engineer helping uh software developers enabled a an easier software development life cycle as much as I can and I seen a lot of um issues uh there around CI/CD but also in how they maintain their repositories and in my current role I'm helping my customers with overall AWS adoption but my main focus was around AI as I think That's most of what we all did uh the past year. Uh so basically AI coding assistants, chatbots and how we can help our developers and our business succeed. So I can bring some from my uh experience and conclusions of that uh to the table. >> Fantastic. Thank you. And yes, we will be talking about AI, not exclusively, but it will be featuring today. But before we get into all of that, uh Reggie, so nice to have you here today. Could you tell us a bit about you and again you know what what your passions are in this area why you're here today. Thanks. >> Absolutely. Absolutely. Hey everybody, I'm Reggie Davis. I am a senior site reliability uh engineer currently for a start Australianbased startup uh named Airlock Digital. I work with uh Elastic and Home Depot and SlumberJ in the past and uh I specialize in incident management. Um, and so as a result, uh, software maintenance is a is a thing for me, um, because I typically see the result or the outcome of the, uh, you know, bad things getting introduced into production environments. And so I have a a a very much so strong passion uh, for this topic. Uh, especially in the age of AI, I think it's probably more important than ever to discuss software maintenance. And uh, I'm really looking forward to the conversation we're going to have today. >> Fantastic. fire fire prevention not firefighting is always the best way I think or that's how I feel anyway and finally tal uh so great to have you here over to you >> uh thank you so my name is T I'm a co-founder and CTO and CEO of Draft and Draft is an agentic platform for software maintenance reduction and elimination that's what we do uh I founded this company because before Draft I was the head of DevOps and platform engineering at big panda and spot IO uh and I saw firsthand you know the how much time uh and how much of our budget goes into keep the lights on uh versus innovating and creating new stuff. uh and most of my time and most of my job was how can I enable the developers and the rest of the teams to better prioritize or better understand the impact of software maintenance and tech that on our uh production environment and our ability to uh create new value. Uh that's what makes me so excited about this topic. it it's kind of funny because it's the most boring part of software development, but it's also the most important part of it. Uh, and the fact that it's still stuck in 2015, uh, is something I'm I'm actively trying to solve. So, that's why I'm here. >> Well, again, if you've got opinions, if you're out there watching, you think it's the most boring or maybe the most interesting, please do share your questions and thoughts with us. Um, I'm really excited though to discuss this topic, to to get into it. I know that everybody's got some really fantastic experiences, different opinions. Um, so yeah, we are talking about why software maintenance is stuck in 2015. Um, 2015 was actually the year that the original Apple Watch um, released. It's the year that samesex marriage was legalized in the US and Windows 10 was released as well. So, a lot has changed in the world since then, yet a lot also hasn't. Um so today we're going to be covering some really practical um experiences from our panelists. We're going to be hearing some fantastic tips and advice for you to hopefully take back to all of your teams. Um but first we wanted to sort of sense check that everybody's on the same page on the topic. So we're just going to start by um talking through and Reggie hopefully you can uh talk through this with us about what we mean by software uh software maintenance. Why are we here talking about it? Why should people care about it? I know that we've heard a little bit in the intros. Um, but yeah, let's let's get that definition out there. What do we mean by software maintenance? >> Absolutely. I think typically like the way I like to describe to my teams is I like to look at software applications like a home, right? It may take you three months, four months, six months to build a home, but you may be living in a home for the next 30, 40, 50 years, right? Are you going to build memories? All of these things are going to happen in this home. And a lot of people get so caught up in the build that a lot of people forget about the actual maintenance and the overhead that comes with the home. It's going to be light bulbs that need to be changed. We got to uh change out the air filters. We got to mow the grass. We got to do all of these things. And those little things over time add up a lot. And so I think uh far too often um our mental models have not necessarily updated to kind of recognize software as that. we just think we can keep building and building and building on to it, but if the home starts off as a as a one-story home and then you add two more stories, can't be surprised when you have foundation issues in a couple of years. And so I think as a result, um I think a lot of times things have moved so fast and we focus so much on like let's let's introduce new features, let's do all the nice cool things that everybody's doing that a lot of times we overlook the maintenance. And so, uh, I think it's extremely important, especially now that we're moving as fast as we are with AI being introduced into the mix. It's extremely important to really talk about maintenance and actually have uh procedures and structures and standards around it because at the end of the day, your leaders or your CTO's or whoever, nobody's going to go and say, "Well, I'm blaming the AI." They're going to look at you, you know, they're going to look at the person that that merged that PR in, that that brought that code in, all of that kind of stuff. And so now more than ever, I think operations and and just the the maintenance overhead that comes with building software, I think it's is it's is more important than ever to talk about these types of things. >> I'm really trying hard not to make the snarky comment at the moment about the leaders blaming AI, which is kind of in the news at the moment. Um but I will uh resist from that. Um but yeah, fantastic. Thank you. And I think that um that that kind of investment and knowing how to talk to your senior leaders, knowing how to kind of sell the value of that as well is super super important. And I think that's something that that we'll likely um touch on a little bit. Um but I'm also really hoping that we can um set the scene a little bit. um Hila, I'll pass over to you in a sec of and we've got this this title of software maintenance being stuck in 2015, but I'd love to hear a little bit of more about um the aspects of maintenance that you feel have changed over the years. Where are those trends? What what has differed? Um and where are the bits that haven't? Those are the bits that we we're sort of obviously talking about a little bit where everybody's getting stuck. Um but what have you seen change and and what have you felt has stayed the same since around then? >> So I would leave the the core parts to people that actually did development here. I will currently focus on the peripheral which is still very very important. For example security okay all of the vulnerabilities that developers don't like to deal with and they introduce packages and in the requirements they uh use a specific package. But what if they there is a CVE or what is there any vulnerability that they need to address? It's the job of the DevOps engineers to incorporate um scanning tools in the CI/CD and if something happens then we will tell the developers and maybe they will fix it maybe not and then that's a hideous part to get to production in a state where we are not sure what do we have false positives yes no so all of the the topic of security vulnerabilities is something that I think got addressed very well um in the in the upcoming years after 2015 uh some tools better than others to to address false positives to help developers deal with it before getting to production before not getting to a place where it um blocks any deployments to production for example. So all of the this thing is very important and usually developers don't like to to deal with it. They just want to write code and that's it. But security vulnerabilities is something that is part of the the day-to-day and nobody can really ignore that. So I would say this is one thing that I personally as a develops engineer uh um dealt with it. Other aspects are um whether developers understand or would like to take that the fact that software maintenance is al is only the software development only their code or also the other parts like CI/CD some developers say no no devops and should do it and that's it and some developments say no I'm building the image I'm building the all the dependencies I should be the one to handle also the deployment to dev and and then production Yeah. So, this also got addressed. Not quite as good as I would have hoped because it's still a matter of culture and perspective, but it is at least something that was addressed. And um yeah, so that's the peripheral stuff that I got to personally uh um tackle, but I will I think we'll go to AB to to discuss the hardcore parts of software maintenance. maybe I'll jump in and add my take on this one. So I I'll start by what has changed. So I feel like even before the AI uh revolution or the era that we are seeing right now, the surface area exploded. Okay, much more microservices, dependencies, manage platform, the release velocity was much higher even before the AI if we compare it to 10 years ago. So everything has changed cloud SAS open source change continuously and it's not something that we're managing. So it's someone's else's code running in our production systems and all these moving parts and all these interconnections is something that someone needs to be in charge of. Um what has changed also I guess our expectations from different uh owners uh the code owners or the the the devops of platform engineering teams the rise of IDPs all these things changed what hasn't changed and this is the reason we are here today is the fact that software maintenance is still reactive and we are only dealing with it when it's too late or something is burning or there is like a a huge shout from someone in the organization saying we must deal with it right now because something is about to happen or already happened. It's still ticket driven uh instead of I'll say risk driven or part of the business decisions. Um and yeah and if I'm adding AI to everything I'll say that AI has changed the way we write code. So now we write code 10 times more than before or even more. Uh but what hasn't changed is our capacity to maintain this code. So AI is not working as well uh in maintaining on or having the full context of what's going on as it works when it's generating generating new code. And that's one of the biggest problem we need to solve right now because uh the the gap between the velocity or frequency of changes to what we can actually maintain and uh you know invest in keeping things running that that's the big the biggest issue that we have today. Um yeah I guess that that's my take on this one. Thank you. And I would love to go over to to AB. Um AB, welcome again. I know that you've experienced some some pain points. Uh might have some great examples to share with the audience today. So could you talk us through um maybe you know what the biggest pain points you have experienced in the area of kind of software maintenance are? >> All right. Um, as it regards pain points, I would say that two stand out for me. And the first one is something everybody whines about every time. Tech debt. But the funny thing about tech debt is we often define it as a conscious decision to take a nonoptimal path to achieve a goal in the short term. However, majority of the tech that you see, they weren't conscious decisions. They are just bad code and poor designs that could have been written differently from day one. And this causes like two major problems. Let's start with the bad code. First of all, that spreads in some cases. New journals come in, they assume it's the standard and then they propagate it. Before you know, in a situation where there's no culture of keeping track of tech debt or areas that need some rework, you just notice that things start getting worse and it's more difficult to maintain something the more you postpone it. I like the um the analogy that Reggie used about a home. It's like when people are building, they're focused more on the building. They don't think about the fact that this might be a bungalow now but maybe we want to make it a duplex later or this may be a one story now but maybe want to make it two stories later. It's just about what's the requirement now and then they work with that and then it becomes really hard to maintain the code. The second thing is even when tech debt is intentional we never really get back to it. I have seen to-dos that are 3 years old and I had to personally ask like is there anyone planning to actually do this thing because this to-do thing here is like 3 years old. So we never get back to it and um many times because things currently work and we have no push to rework them or keep the system maintained. We wait till there's a breakage in the system or there's a huge bottleneck and then that's when we realize as Tal said we're more reactive as opposed to proactive. The second pain point would be something that I would say Hila is very passionate about and that's documentation. Software is incredibly hard to maintain when you do not have the slightest idea why it was built the way it was. someone could make a small change and you think it's totally unrelated and you're like maybe everyone says production is down and you're like can't be me what I did is totally unrelated and it was you >> can I use reactions I want to use reactions and put you some a lot of confetti please so on I mean oh my god >> but that's because there's no like there are no docs and the thing is people think of docs as this huge page documentation can ring anything from comments in your code to say maybe don't touch this part because it's related to this other part or something that can help people understand how things work. They can be RFC's erds but in whatever come they in in whatever form they come in it's um they totally make software maintenance easy and and this is an area I've seen a lot of teams struggle in or struggle with. Something I would say is that these pain points become very obvious when you find it difficult as a team to adapt to changing requirements and you'd see that when product comes in and says oh we just need to make this small change and engineering it's like that must be easy and then you go touch the code and you then realize that the system was not built to be extended and it hasn't been properly maintained and suddenly a small change leads into a bigger project but that's because we didn't do the right thing in the first place. So yeah, those are the two main pain points I have experienced. >> Fantastic. Thank you. Uh well, not fantastic that you've experienced them, but I think it is, you know, the reaction you've got here in the in the group I think is probably reflective of how people are are feeling outside as well. Um I would really love to hear from Reggie on this because you've talked about a lot of things there that are kind of baked into the culture. So standards juniors coming in feeling like okay this is the standard that we we need to align with. Um so Reggie how um how would you describe the the key cultural drivers that really contribute to a successful culture uh of maintenance software ownership all of all of that good stuff. Um if we're going to flip it around we've heard about the pain points. What does a great culture look like? What should people be doing in a practical level um to turn that culture around or to to get to a place that they they aspire to? >> Absolutely. I love this question. Um it's funny. It we had an incident the other day at work and um I had a conversation with a manager and I told him, you know, we're a startup. We, you know, we're figuring things out and uh one thing I was telling him I'm like, you know, I believe in a blameless culture, right? But I also believe believe in a accountable culture, right? I think a lot of times people just say, "Oh, well, it's blameless." Like, we don't blame people. But you have to take accountability, especially from leadership, right? Because to the point that AB was making, those juniors, those, it ain't necessarily got to be a junior. It could be just a person that's on board into the company. They're coming in and they're looking at the code base and they're going to follow the patterns that are already laid in front of them. And if and if and if people aren't able to be able to go to the people that have written the code and do all of the things and talk about, hey, why we make this decision or what we doing here and all of that kind of stuff, then what is going to happen is it's like now this person is going to create a brand new mental model of what they should be doing and they're not necessarily following the patterns, right, that maybe leadership believes that they should be following. Which leads me into my other point, which is the other part about making a great culture is discipline. You have to have discipline on a leadership level. And so even if that means as a senior engineer, I know I don't like writing documentation and well that's not necessarily me. I love writing documentation. But even if I don't like writing documentations or I don't like doing ADRs or I don't like scoping out my projects or whatever it is, you have to do it because this is the road map. This is the blueprint that everybody else is going to follow. Not just over the next three months, but really for years to come. Because typically once that code goes out as AB said like you might intentionally introduce tech debt into your environment but the reality is is that you may not get back to it 6 months a year you may never get back to it. So at the very least it's important to have strong discipline around areas when it really when it comes to communication communicating all of these different ideas having diagrams having docs leaving comments in the code because you don't know the learning style or the way that people are going to be looking at the code and the environment when they walk into your when they walk into your environment. And so it's important to have really really strong discipline um when it comes to these areas because if not then people are going to go off like people gonna go off and start building all these mental models and then the maintenance becomes even harder because you got a team of seven or eight people and you got four or five different mental models around the business domain and that's extremely difficult to manage over a course of time. >> Let me just say something there. Let me just add something about the whole drive for culture. I noticed that some people do feel that if I report something that means I'm the owner and so they refrain from actually doing that you you encounter tech debt. you find that this isn't right but instead of saying oh this isn't right we should change it you're scared that if I say that then I have unintentionally availed myself as the owner or the person who has to change this and so they actually do nothing so I agree that we should have a culture of logging things to say okay or tracking tech there to say I found this thing this is this is what I think it is this is how I think we should evolve it and just keep it there so we have that visibility And then we can begin to think about how we want to tackle things >> completely. >> Absolutely. >> Reggie, I just wanted to follow up on your point um for my clarification, but also it might be an interesting point as well of you talked then about accountability uh and leadership accountability as well. My take is um that I'm interpreting that to mean kind of leadership uh of all levels. Is that kind of what you mean? Do you mean that there should be accountability throughout the org or you >> Yeah. >> No, absolutely. It got to be throughout the org because like when we talk about culture, it's engineering culture. It's not the culture of a team. Yeah. Obviously, your team may have your own culture, but at the end of the day, you all work for a business and the business has these objectives that they're trying to drive towards. So it has to be the culture around the engineering. I think that's something that that can be very difficult especially as you scale out a lot and I know we had a lot of issue like this when we were at when I was at elastic because you know you got people across different parts of the world and they all have different mental models of what's going on. So, it's extremely important for leadership on every level to really embody these ideas culturally around the engineering culture that we want to build because if not, you're going to have people coming in being like, "Oh, well, y'all y'all aren't doing this. Well, we did this at my last company." Then they're gonna come in and try to do their own thing and all this kind of stuff and they might not necessarily be the culture that they're trying to develop there. >> Great. Thank you for clarifying. I just wanted to I know that that's a whole topic in itself kind of like what is leadership? what level, you know, does leadership kind of kick in as a an attribute? Um, so yeah, I think that's a super super important point when you're trying to build out the culture. Um, but kind of moving, not moving away from people, um, but thinking less about individuals and more about tooling. Hila, I know that you've got some loads of experience and some really great opinions uh, around AI, particularly when it comes to software maintenance. So I'd like to ask how you see the balance of maintenance responsibilities playing out between humans and AI particularly as more and more companies more and more teams adopt um the the tools that we're seeing is so common place nowadays. >> So the the term vibe coding emerged and everybody got excited about it but it's good for dev. It's good for prototypes. It doesn't good it's not good for production. So I think that once I hope people will understand that it it's good until a certain point that's it but we can see now tools emerging understanding that so basically taking AI and uh having the built-in notion of not vibe coding but how I call it or AWS call it specdriven development to use AI but in a very methodological I hate this word methodologic I think way of doing things of of developing um a feature for example. So again I didn't mean to do a shame shameless plug but here it is very short kirao our IDE it is it has built-in specdriven development and why is it is so important because it forces the the developer to work in a certain way. So once you say in a natural language I want to build a feature or I want to add a feature to my product that does ABC then the ID automatically says okay cool I'm going to build a spec that introduce the requirements you need to go over it see if it makes sense if this is what you meant has um aligning to the user stories to see that this is something that you actually want to do and understand why then to the design and then to the actual tasks And that way because if you don't do that not all developers will do it themselves like okay let's work method you know in a in a very organized way let's do it you have to have a very built-in mechanism to make developers do it and then once you have it you AI is is fully at your disposal you can do whatever you want with it it it does everything it you can al also leverage uh agents to do h to handle a lot of the tech that in the background while work on in the ID. So this is awesome assuming that it leverages this uh approach because that way you can um take the full power of AI but in a somewhat constraint way that will help you create better and quality and more quality uh u products and and and features to your production environment. So AI is great, but you need to make sure it follows a certain um methodology to make sure that you actually create something that is worthwhile to use. >> Okay. I didn't know whether we'd have any other people trying to jump in on that one. >> Yeah, I can. I have my opinion. So you know I'm a bit biased of course building a tool solving tech that and and software maintenance friction but I I will try to reframe uh the work or or what we're trying to do here and say that you know I mentioned before that what has changed the surface and now we have a lot of open source tools and third party vendors and managed services and cloud providers and each one of them comes with a life cycle or or a end of life timeline. So if you're leveraging I don't know RDS or Kubernetes or whatever technology it is in any cloud provider it comes with a clock and the moment you started using it you need to plan ahead the next upgrade and it's never a vanilla upgrade. So you want to upgrade your uh I don't know posgress or open search or uh MongoDB database. So the data the database team or the devops team are in charge of the actual change of the database but the development team needs to understand the breaking changes the change of behavior uh all the bug bugs introduced or fixed in the next version and all this work they can't solve it because it's a black box and a black box someone is managing a technology not you are not the subject owner expert and you also cannot not uh folk this technology to fix something. You are dependent on someone else to do the job and you are dependent on understanding how it affects you and what you need to do in order to keep your business running. So I guess what is missing is first of all uh visibility to the entire tech stack the different layers of the tech stack because it's not just infrastructure not just code not just runtimes or operating system it's it's a whole uh and the second thing is a shared language so you mentioned it before I think Reggie when you spoke about leadership and the organization needs to speak the same language uh and in security they were able to do it And you know everything is about risk and you have critical and high and medium and low and then you it's easy to to you know get a CV score it some way and then you have an SLA to deal with it. That's something that security teams did very well uh in order to react to something that is not under their control. Um we need to find the same language uh and to find a way to make maintenance and routine maintenance and uh something boring again not something that all all the organization like all ends on deck because it's about to break production how we can be predictive and be proactive and take all the friction and maintenance toil that I just mentioned you know someone is getting this message saying uh this database needs to be updated by this eight, but then you start the meetings, right? You have a meeting with the leadership and you say, "Hey, we don't know how it affects us. Let's schedule some time in the next sprint to do some research pre, you know, two weeks later, the next sprint. Okay, now we need to prioritize it. Is it important enough? Not different teams need different changes. For some, it will be uh you know a a green green field just upgrade, nothing will break. For others, it's a refactor of the entire codebase." So all these main you know I'll say manual frustrating work that no one comes to job and say hey I'm excited about researching how MongoDB broke my production today. No one does this. So it it's something that we need to find the right tools and or the right uh methodologies to solve. Um so so that's the biggest opportunity I feel uh we can introduce right now to this area. and of course leveraging AI to do most of of the parts. >> I think I've actually been really lucky in that I've worked with a lot of engineers I think relatively speaking who really enjoy that kind of work and who are super proactive and take great ownership. So I know I'm probably the exception. Um but yeah that's that's I think a really really great way to look at it. Um so um yeah thank you for sharing that. Um, are there any other opportunities tal that uh that you haven't covered? Because I know that we were thinking about AI, but are there any other kind of really really great opportunities that people should be open to thinking about or do you do you feel like you you touched on everything there? No, I feel like people should start talking about a system of record of software maintenance, a way to manage it as a first class citizen and not just something that uh you know it's reactive and we deal with it when we have a fire that we need to firefight. Um and we also need a system of record uh to find a way to reduce the manual work and repetitive repetitive work that we are doing in this areas. So I guess I kind of talked about it before but but we need to structure it in a way and you see that Gartner is trying to come with some methodologies to how uh you know to to prioritize and and fit different initiatives into boxes. Uh and we see a lot of conversation in this area. It's really one of the emerging trends uh now with AI of course uh because it just amplifies the problem and people meet it in production much uh more more often. Uh but yeah, this is the one thing that I I will do tomorrow morning if I don't have a systematic approach right now that that's the one thing I'll do tomorrow. >> Thank you. Thank you. Uh just a quick reminder to people watching if you want to ask any questions to the panelists. We may have a little tiny bit of time. Um we'll see. Thank you to the person who's literally just sent one in. So we may not have as much time now. Um but if you do want to send in any questions then we'll either try and answer them live um on the call itself or we will jump over to the Slack channel um on the lead dev Slack to answer those afterwards. Um but we'll sort of we'll move towards the the tail end of this. So AB, I would really love to get your thoughts. So um we've heard a little bit from TAL in terms of opportunities and recommendations, but do you have any advice to people who are looking to improve their software maintenance right now? So what practically should they be taking back to their teams after watching here today? That's a very interesting one. I would say that it's a it's kind of a combination of what everyone has said. First of all, culture is important. It's important to begin to build a culture where people don't see maintenance as an afterthought or something that we do after we ship. No, you need to begin to think about it as from the first line of code the maintenance begins. So, we need to start to ship what's maintainable and what's extendable. The second thing is something I feel a lot of people struggle with and that's automation. AI is here to stay whether we like it or not. We're in the AI era. So, um we you should try to automate as much as possible. However, we have tools that are built for this. So, as much as you can automate um tasks that are boring, but we know that should actually happen, let's try to use tools that are built for that to do those. And the next thing will be understanding the business and the environment. Some people make a case for maintenance to their um maybe senior their um senior leadership and they say um things are not moving fast enough because we're not doing the right things but then they actually comfortable with the speed. So that's not a good case for the business. So you need to understand the business so that you can make a good case for it I would say. Well, that actually leads really nicely into one of the the questions that's been asked in the Q&A feature. Um, and I'll just uh read that out quickly, which is what are ways that engineering leaders can quickly pitch proactive maintenance activities to product owners, business owners, and other non-technical stakeholders in their organization. Put another way, how can we avoid the project management overhead of maintenance killing proactive maintenance drive from engineers? Uh, and I'll actually just paste that in the chat so that our panelists can read and absorb that if they uh can't see it. Anybody wants to share any opinions on that one? >> Yeah, I I can I'll share what I did, you know, in previous companies. uh I just tried to create a shared language you know when when things actually got prioritized when there was a deadline right when you say it's not something we should do we can't not do it by this date because this will be the business impact um but you don't want to use this pure mechanism all the time right so you need to find a better way to frame what's important to the business and then say Hey uh first of all I I'll stop for a second and say some organization if you ask them they will say that they have a bucket of 20 40 60% of their uh quarterly uh I'll say bucket to software maintenance and keep the lights on. So that that's a a common practice and it happens because they don't know what will happen but they had enough issues before to to understand that something will pop up. So being proactive is not just saying uh we will keep this time aside for the next outage to come or the next problem to come is to be more uh proactive about it and say hey this is the things that we already identified for the next 6 months or 9 months that we must deal with. Um here's why we believe we must deal with it. This is the business impact. This is how it affects our ability to deliver new features. Here's how it prevents us. Uh, you know, here's the SLA breach. Here is the uh I don't know the the the vendor sunsetting something. All this information if you get it in advance, it kind of solves the discussion of uh to try and convince people and do all these roundts around uh the project management side of things. So, so we all now speak the same language and we understand why it's important, why should I care and why it sits under my roles and responsibilities or under my ownership and you can go ahead from pitching to actually reasoning uh in a much higher uh layer. So most of the time what I did before I had this kind of mechanism I tried to tie up uh my initiatives or the things that I wanted to uh achieve in this quarter or the next quarter with the company OKRs. So a and it's kind of what I'm doing right now as a CEO uh you know selling to companies I'm trying to understand what are the top priorities they have whether it's leveraging AI to you know release engineering capacity or preventing outages or just reduce the the manual work they're doing and then I I try and translate what draft is doing to the same uh objectives. So if you'll be able to speak the same language the business talks, that's the major step you'll take forward in in changing the way the culture of the organization work. I hope I was able to answer this one. >> I want to add something to that really quickly and that's because the question says how can we quickly pitch right? So it's like how can I just quickly put that in there? And two things I would say uh I always ask how fast do you want to move and how effective do you want your software to be? That's the fastest way to just pitch it. So how fast do you intend to move? Oh, we would like to um ship seven features in seven weeks. Okay, if you want to do that then these are the things we have to do proactively to enable the team to do that. How effective do you want software to be? Oh, I want um a lower latency. I want this or that. So it's like as he said, tie it to the business outcomes and objectives and every business loves to move fast. Every business wants to make money. So yeah, if you can frame it that way, that's a way to quickly pitch it. >> Fantastic. >> Not only that, it's just the fact that if you find the reasoning for that proactive work, how it will affect them, then that's it. You're done. >> Yeah. I I think and I just just to piggyback on that like one thing that I I find um we kind of sometimes as engineers we fall short on is like we always have our engineering hat on but we don't never put our business hat on, right? Or we don't put our finance hat on. And a lot of times when we got to go and talk to executives, they're not just thinking about the X's and O's, right? They're talking about the dollar signs, the commas, and the decimals. And so as a result, like I think that's a muscle that does have to be worked. Like we got to get out of the mindset of like oh okay like we going to ship code in a week two weeks. No like put your business mind on. You know what I'm saying? Put your business hat on and think from the f from the reference of the business because it becomes a lot easier to communicate to your leaders when you're speaking their language. You can't expect them to come into your world. You kind of got to step into theirs. >> So unfortunately we've only got a couple of minutes left. Um, we do have some um some questions that have come in um with the um with the Q&A feature. Um Reggie, thank you also for tapping away in the background and kind of asking answering some of those async. So, appreciate your work there. Um I just did want to kind of draw us to a close for the the live stream though. Uh it's been a great discussion. I've really enjoyed hearing from all of you. I hope that everybody watching has really enjoyed it too. And some of the notes that I've been scribbling down are just about the the importance of culture. Um from AB you I believe said uh maintenance starts from the first line of code and we talked a bit about how the balance between kind of proactive and reactive maintenance is very different and can lead to to very different outcomes. Thinking about the automation, thinking about um automating the boring tasks, using appropriate tools of which there are a lot out there. Um, and also I love the the analogy of the house. Um, I'm I often think about it in terms of like gardening, but I love that point about it's a bungalow now, but where might it go into the future? What's the potential? Um, I I also write down the fact that everything comes with a clock. Um, and that we we need to put our business hat on as well. Um, something that I am similarly guilty sometimes of not doing enough. Um, so I just wanted to thank all of you again for all of the amazing insights. Just to uh reiterate in terms of anybody who hasn't had a question answered yet, we're going to go over to the lead dev slack um in the panel Q&A channel hyphenated. So if you want to come and continue the discussion, we're all going to head over there now. And if you're not signed up already, you can get there by going to leaddev.com hyphen u leadv.com/joinhyenlack. So, thank you so much again for joining us today and we hope to see you again next time. Bye. >> Bye., Why Software Maintenance Is Stuck in 2015, YouTube, 01kg850wvq7gpyw1td21g1wwwe.