Why Software Maintenance Is Stuck in 2015 - CourtneyR.dev's 2nd Brain

Why Software Maintenance Is Stuck in 2015 ![rw-book-cover](https://img.youtube.com/vi/gMn6JkLDaGc/maxresdefault.jpg) 🔗 **Source:** [Why Software Maintenance Is Stuck in 2015](https://www.youtube.com/watch?v=gMn6JkLDaGc) > [!note]+ Document Notes > tags: [software-maintenance, tech-debt, devops, engineering-culture, ai-coding] > author: Lead Dev > source: YouTube > reference: https://www.youtube.com/watch?v=gMn6JkLDaGc > date created: 2024-01-15 10:30 > > # 🏷️ Title: Why Software Maintenance is Stuck in 2015 >  ## 🧰 Action Inbox - [H1] Establish systematic maintenance record — create first-class citizen system #culture - [H2] Implement spec-driven AI development — prevent vibe coding in production #ai-tools - [H3] Create shared maintenance language — tie initiatives to business OKRs #communication ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Lead Dev Slack Community](https://leaddev.com/joinslack) - [Draft Platform](https://draft.dev) ## 📝 Summary - Expert panel discusses why software maintenance practices haven't evolved since 2015 despite massive changes in development velocity - Core problems: reactive approach, lack of systematic maintenance records, cultural issues around ownership and documentation - AI has accelerated code writing 10x but hasn't improved maintenance capacity, creating dangerous gaps - Solutions focus on culture change, automation of boring tasks, and speaking business language when pitching maintenance work - Key insight: maintenance must be treated as first-class citizen from first line of code, not afterthought ## 📖 Main Content The panel identifies a fundamental disconnect: while software development has transformed dramatically since 2015 with microservices, cloud platforms, and AI-assisted coding, maintenance practices remain largely reactive and ticket-driven. The surface area for maintenance has exploded with dependencies on third-party services, each with their own lifecycle and end-of-life timelines, yet organizations still wait for fires before addressing maintenance needs. Technical debt represents a major pain point, often resulting from poor initial decisions rather than conscious trade-offs. Documentation gaps compound the problem, making it difficult to understand why systems were built certain ways. Cultural issues around ownership create situations where people avoid reporting problems for fear of becoming responsible for fixes. AI tools show promise but require disciplined, spec-driven approaches rather than "vibe coding" to produce maintainable production code. The key is creating systematic approaches to maintenance that treat it as a business priority with clear language and metrics that resonate with leadership. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/gMn6JkLDaGc?t=0) — [H1] Panel Introduction and Context - Key idea: Discussion on why software maintenance hasn't evolved since 2015 - Evidence: "2015 was the year that the original Apple Watch released... a lot has changed in the world since then, yet a lot also hasn't" #### ⏱️ [03:15](https://youtu.be/gMn6JkLDaGc?t=195) — [H2] Software as Home Analogy - Key idea: Software applications require ongoing maintenance like homes - Evidence: "It may take you three months to build a home, but you may be living in it for 30-50 years" #### ⏱️ [05:42](https://youtu.be/gMn6JkLDaGc?t=342) — [H3] Security Vulnerabilities Progress - Key idea: Security scanning and CVE management has improved significantly since 2015 - Evidence: "All of the vulnerabilities that developers don't like to deal with... scanning tools in CI/CD" #### ⏱️ [08:30](https://youtu.be/gMn6JkLDaGc?t=510) — [H1] Surface Area Explosion - Key idea: Technical complexity has exploded while maintenance capacity hasn't grown - Evidence: "AI has changed the way we write code... 10 times more than before but what hasn't changed is our capacity to maintain this code" #### ⏱️ [12:15](https://youtu.be/gMn6JkLDaGc?t=735) — [H2] Tech Debt Reality Check - Key idea: Most "tech debt" isn't conscious trade-offs but simply bad code from the start - Evidence: "Majority of tech debt... weren't conscious decisions. They are just bad code and poor designs" #### ⏱️ [15:20](https://youtu.be/gMn6JkLDaGc?t=920) — [H3] Documentation Crisis - Key idea: Lack of documentation makes maintenance extremely difficult and dangerous - Evidence: "Someone could make a small change... production is down and you're like can't be me" #### ⏱️ [18:45](https://youtu.be/gMn6JkLDaGc?t=1125) — [H1] Cultural Accountability Framework - Key idea: Successful maintenance culture requires both blameless and accountable practices - Evidence: "I believe in a blameless culture... But I also believe in an accountable culture" #### ⏱️ [22:10](https://youtu.be/gMn6JkLDaGc?t=1330) — [H2] Leadership Discipline Requirements - Key idea: Senior engineers must model good practices even when they dislike certain tasks - Evidence: "Even if I don't like writing documentation... you have to do it because this is the blueprint" #### ⏱️ [25:33](https://youtu.be/gMn6JkLDaGc?t=1533) — [H3] Ownership Fear Problem - Key idea: People avoid reporting issues due to fear of becoming the owner - Evidence: "Some people feel that if I report something that means I'm the owner and so they refrain" #### ⏱️ [28:15](https://youtu.be/gMn6JkLDaGc?t=1695) — [H2] AI Spec-Driven Development - Key idea: AI coding requires methodological constraints to produce maintainable code - Evidence: "Vibe coding... is good for dev, prototypes. It's not good for production" #### ⏱️ [32:40](https://youtu.be/gMn6JkLDaGc?t=1960) — [H1] Third-Party Lifecycle Management - Key idea: Every technology comes with a clock requiring planned upgrades - Evidence: "If you're leveraging RDS or Kubernetes... it comes with a clock" #### ⏱️ [36:22](https://youtu.be/gMn6JkLDaGc?t=2182) — [H3] Shared Language Need - Key idea: Organizations need common vocabulary for maintenance like security teams have - Evidence: "In security they were able to do it... critical and high and medium and low" #### ⏱️ [39:45](https://youtu.be/gMn6JkLDaGc?t=2385) — [H2] Maintenance as First-Class Citizen - Key idea: Maintenance should be planned from first line of code, not afterthought - Evidence: "Maintenance begins from the first line of code... we need to start to ship what's maintainable" #### ⏱️ [42:18](https://youtu.be/gMn6JkLDaGc?t=2538) — [H1] Business Language Translation - Key idea: Engineering leaders must speak business language to get maintenance buy-in - Evidence: "How fast do you want to move and how effective do you want your software to be?" ## 📚 References - [Lead Dev Community](https://leaddev.com) - [AWS Solutions Architecture](https://aws.amazon.com) - [Draft Agentic Platform](https://draft.dev) - [Kirao IDE](https://kirao.aws) ## 🗣️ Paraphrase - Software maintenance practices haven't evolved since 2015 despite massive changes in development speed and complexity - The core problem is reactive rather than proactive approaches, with organizations waiting for fires instead of preventing them - AI has created a dangerous gap by accelerating code creation without improving maintenance capabilities - Success requires treating maintenance as a first-class business priority with systematic tracking and clear communication ## 📰 Newsletter The software development world has transformed dramatically since 2015—AI assists coding, microservices dominate architectures, and deployment velocity has skyrocketed. Yet maintenance practices remain stubbornly reactive and ad-hoc. This expert panel reveals why: we're writing code 10x faster with AI but haven't improved our capacity to maintain it. The result? Growing technical debt, documentation gaps, and cultural issues where engineers fear reporting problems. The solution isn't just better tools—it's treating maintenance as a first-class citizen from day one. Start by creating systematic maintenance records, implementing spec-driven AI development, and most importantly, learning to speak business language when pitching proactive maintenance work. Resources: [Lead Dev Community](https://leaddev.com), [WordPress Developer Docs](https://developer.wordpress.org/), [WP-CLI Maintenance](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: create maintenance-focused talks demonstrating ROI of proactive approaches - Education: develop workshops on AI-assisted maintenance and spec-driven development - Developer experience: improve documentation standards and maintenance tooling - Community management: facilitate discussions on maintenance culture and best practices #### WordPress - Core: implement systematic tracking of maintenance debt and lifecycle management - Documentation: create maintenance-first documentation standards and templates - Community: develop mentorship programs pairing senior maintainers with newcomers - Training: build curriculum on sustainable development practices and technical debt management - CLI: expand maintenance commands for automated dependency updates and health checks #### Community - Maintainers: establish maintenance office hours and cross-project knowledge sharing - Contributors: create first-issue programs specifically for maintenance tasks - Sponsors: fund dedicated maintenance roles and systematic improvement initiatives ## 🧪 Hypotheses - Organizations treating maintenance as first-class citizen will have 50% fewer production incidents - Teams using spec-driven AI development produce more maintainable code than vibe-coding approaches - Engineers trained in business language get 3x more maintenance initiatives approved - Systematic maintenance tracking reduces emergency firefighting by 40% ### 📊 Methodology - Survey engineering teams on maintenance practices and incident frequency correlation - A/B test spec-driven vs vibe-coding approaches measuring long-term maintainability metrics - Track success rates of maintenance proposals using business vs technical language ### ❓ Questions - How can we measure maintenance debt systematically across different technology stacks? - What specific constraints make AI-generated code more maintainable in production? - How do we scale maintenance culture practices across distributed global teams? ### 🔮 Future Research - Development of standardized maintenance debt scoring systems across platforms - Investigation of AI agents specifically designed for maintenance tasks - Study of maintenance culture patterns in high-performing engineering organizations ### 💡 Implications - Practice: Maintenance must shift from reactive firefighting to proactive systematic management - Policy: Organizations need formal maintenance allocation in quarterly planning (20-60% bucket) - Education: Engineering curricula should include business communication and maintenance planning - Funding: Maintenance roles deserve dedicated funding rather than being treated as overhead ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 12 #### 👀 Visual learners - Present: Panel discussion format, speaker identification - Improve: Architecture diagrams showing maintenance complexity, visual debt tracking dashboards #### 🔊 Aural learners - Present: Full video discussion with multiple expert perspectives - Improve: Timestamped audio clips highlighting key concepts #### 🗣️ Verbal learners - Present: Rich analogies (home ownership, gardening), clear definitions - Improve: Story-driven case studies of maintenance transformations #### 🧩 Kinesthetic learners - Present: Actionable recommendations and practical frameworks - Improve: Interactive maintenance assessment checklists, hands-on workshops #### 🧠 Logical learners - Present: Clear problem-solution frameworks, systematic approaches - Improve: Decision trees for maintenance prioritization, metrics dashboards #### 🧑‍🤝‍🧑 Social learners - Present: Panel discussion format encouraging multiple perspectives - Improve: Community forum discussions, peer review processes for maintenance plans #### 🧘‍♀️ Solitary learners - Present: Comprehensive notes and reflection prompts - Improve: Self-assessment tools for maintenance culture maturity #### 🌿 Naturalistic learners - Present: Ecosystem analogies and lifecycle thinking - Improve: Software ecosystem health metaphors, sustainability frameworks ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, speaker identification - Improve: ARIA landmarks for topic transitions, better alt text for visual elements #### Keyboard navigation - Present: Standard video controls accessible - Improve: Timestamp navigation shortcuts, transcript search functionality #### Contrast and readability - Present: High contrast video player interface - Improve: Transcript formatting with better visual hierarchy #### Media and captions - Present: Full video content with transcript - Improve: Professional captions with speaker identification, downloadable transcript ### 🌍 DEIB Assessment #### Cultural breadth - Present: Diverse panel with different company backgrounds and roles - Improve: Include perspectives from different geographic regions and company sizes #### Inclusive language - Present: Gender-neutral technical language, defined jargon - Improve: Plain language summaries, avoid Silicon Valley idioms #### Representation - Present: Mix of technical roles (CTO, SRE, DevOps, Solutions Architect) - Improve: Include more diverse perspectives on maintenance challenges #### Psychological safety - Present: Blameless culture discussion, accountability without blame - Improve: Explicit discussion of learning from failures ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear cause-effect relationships between maintenance gaps and production issues - Inductive strength: Multiple expert experiences supporting similar conclusions - Analogical strength: Home ownership analogy effectively illustrates maintenance concepts #### Fallacies - Hasty generalization: Some claims about AI coding effects lack quantitative backing - False dichotomy: Framing as either reactive or proactive when hybrid approaches exist #### Tone of voice - Overall tone: Professional but conversational, collaborative problem-solving approach ### 🛡️ DARVO Analysis - No DARVO patterns detected - discussion focuses on systemic issues rather than individual blame ## 🎯 Conclusion Software maintenance remains stuck in 2015 because organizations treat it reactively rather than systematically. While AI has accelerated code creation, it hasn't improved maintenance capacity, creating dangerous gaps. The solution requires cultural change treating maintenance as a first-class citizen from day one, combined with systematic tracking and business-language communication. Success depends on leadership accountability at all levels and disciplined practices that prevent rather than fight fires. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Maintenance culture requires both blameless and accountable practices > [!quote] [Why software maintenance is stuck in 2015](https://youtu.be/gMn6JkLDaGc) by [[Lead Dev]] via [[YouTube]]. Published 2024. Accessed 2024-01-15. > "I believe in a blameless culture, but I also believe in an accountable culture." Essential framework for engineering leadership balancing psychological safety with responsibility. [view highlight](https://youtu.be/gMn6JkLDaGc?t=1125#H1) #culture #leadership ID:rw_001 ### [H2] AI creates dangerous capacity gaps in software maintenance > [!quote] [Why software maintenance is stuck in 2015](https://youtu.be/gMn6JkLDaGc) > "AI has changed the way we write code 10 times more than before but what hasn't changed is our capacity to maintain this code." Critical insight on AI's asymmetric impact on development velocity versus maintenance capability. [view highlight](https --- ## Full Transcript [00:12] Hi everybody. Uh a huge thank you today [00:15] for joining us for this discussion on [00:18] why software maintenance is stuck in [00:20] 2015. And this is a lead dev online [00:24] panel discussion created in partnership [00:25] with draft. The discussion today is [00:28] going to last approximately about 45 [00:30] minutes after which both myself and the [00:32] panelists are going to head over to the [00:34] lead dev Slack. Um we'll be answering [00:36] some of your questions there if you've [00:37] got them in the um panel Q&A channel. [00:42] And if you haven't already joined the [00:43] lead dev Slack, you can do so by going [00:46] to leaddev.com/join [00:49] slack. [00:51] We will also hopefully have time to [00:53] answer some of the questions either as [00:55] the panelists are going through and I [00:56] can work them in um or at the end. So if [00:59] you do have anything that you want to [01:01] ask us then feel free to submit them um [01:03] through the uh the Q&A feature on Zoom [01:06] um and I'll get to them like I say [01:08] whenever we can. Um but first we're [01:10] going to get started with just a few [01:12] basic introductions. My name is Sally [01:14] Le. Uh my pronouns are she and her and [01:17] I'm a fractional technology leader and [01:19] adviser based in the UK and I'm joined [01:21] by four incredible panelists today. I'm [01:24] really excited um that they're here with [01:26] us. They're going to be sharing their [01:27] experiences, sharing their insights and [01:30] I'm going to let them all introduce [01:31] themselves starting with AB. So Abby, [01:34] could you tell us a bit about you and a [01:36] bit about why you are particularly [01:38] excited about being here and this topic? [01:40] All right, no worries. Thanks Sally. Um [01:43] hi everyone. and I'm AB. I'm currently [01:45] the CTO and co-founder at [01:49] everyone calls us Metri Fox or Foxes, [01:51] whichever one you prefer. It's a [01:53] monetization platform for AI agents and [01:55] SAS companies. Before Metro, I worked as [01:58] a software engineer on multiple core [02:01] teams and a developer experience team as [02:03] well as an EM at places like Factorial [02:06] and Clue. having been on both sides of [02:08] the aisle, being someone who had to [02:10] maintain painful code bases as an IC and [02:13] also someone then being the person later [02:16] responsible for setting good standards [02:18] and trying to convince the business to [02:20] invest in them. I would say that I bring [02:22] a holistic view to the topic of software [02:26] maintenance and yes, I'm really excited [02:28] that we are discussing it. [02:30] >> Oh, thank you. I'm so glad that you're [02:31] here with us today. And next, I'm just [02:34] going to go over to Hila. So Hila, could [02:36] you tell us a bit again about yourself, [02:38] your background and why you're [02:39] particularly excited to be here today? [02:41] >> Sure. So I'm Hila Fish. I'm currently a [02:44] solutions architect in AWS and [02:46] beforehand I was a DevOps engineer. So [02:49] I'm looking at this uh particular topic [02:52] from both ends. So as a devops engineers [02:55] help as devops engineer helping uh [02:57] software developers enabled a an easier [03:01] software development life cycle as much [03:03] as I can and I seen a lot of um issues [03:07] uh there around CI/CD but also in how [03:10] they maintain their repositories [03:12] and in my current role I'm helping my [03:16] customers with overall AWS adoption but [03:19] my main focus was around AI as I think [03:23] That's most of what we all did uh the [03:26] past year. Uh so basically AI coding [03:28] assistants, chatbots and how we can help [03:31] our developers and our business succeed. [03:34] So I can bring some from my uh [03:37] experience and conclusions of that uh to [03:40] the table. [03:41] >> Fantastic. Thank you. And yes, we will [03:43] be talking about AI, not exclusively, [03:45] but it will be featuring today. But [03:47] before we get into all of that, uh [03:49] Reggie, so nice to have you here today. [03:51] Could you tell us a bit about you and [03:53] again you know what what your passions [03:55] are in this area why you're here today. [03:56] Thanks. [03:57] >> Absolutely. Absolutely. Hey everybody, [03:59] I'm Reggie Davis. I am a senior site [04:01] reliability uh engineer currently for a [04:04] start Australianbased startup uh named [04:06] Airlock Digital. I work with uh Elastic [04:09] and Home Depot and SlumberJ in the past [04:12] and uh I specialize in incident [04:14] management. Um, and so as a result, uh, [04:18] software maintenance is a is a thing for [04:20] me, um, because I typically see the [04:22] result or the outcome of the, uh, you [04:25] know, bad things getting introduced into [04:27] production environments. And so I have a [04:29] a a very much so strong passion uh, for [04:32] this topic. Uh, especially in the age of [04:34] AI, I think it's probably more important [04:36] than ever to discuss software [04:37] maintenance. And uh, I'm really looking [04:39] forward to the conversation we're going [04:40] to have today. [04:41] >> Fantastic. fire fire prevention not [04:44] firefighting is always the best way I [04:46] think or that's how I feel anyway and [04:49] finally tal uh so great to have you here [04:52] over to you [04:53] >> uh thank you so my name is T I'm a [04:55] co-founder and CTO and CEO of Draft and [04:58] Draft is an agentic platform for [05:00] software maintenance reduction and [05:02] elimination that's what we do uh I [05:05] founded this company because before [05:07] Draft I was the head of DevOps and [05:09] platform engineering at big panda and [05:11] spot IO uh and I saw firsthand you know [05:14] the how much time uh and how much of our [05:17] budget goes into keep the lights on uh [05:21] versus innovating and creating new [05:23] stuff. uh and most of my time and most [05:25] of my job was how can I enable the [05:29] developers and the rest of the teams to [05:32] better prioritize or better understand [05:35] the impact of software maintenance and [05:36] tech that on our uh production [05:39] environment and our ability to uh create [05:41] new value. Uh that's what makes me so [05:45] excited about this topic. it it's kind [05:48] of funny because it's the most boring [05:49] part of software development, but it's [05:52] also the most important part of it. Uh, [05:55] and the fact that it's still stuck in [05:57] 2015, uh, is something I'm I'm actively [06:00] trying to solve. So, that's why I'm [06:01] here. [06:02] >> Well, again, if you've got opinions, if [06:04] you're out there watching, you think [06:06] it's the most boring or maybe the most [06:07] interesting, please do share your [06:09] questions and thoughts with us. Um, I'm [06:12] really excited though to discuss this [06:14] topic, to to get into it. I know that [06:15] everybody's got some really fantastic [06:17] experiences, different opinions. Um, so [06:20] yeah, we are talking about why software [06:21] maintenance is stuck in 2015. Um, 2015 [06:24] was actually the year that the original [06:27] Apple Watch um, released. It's the year [06:29] that samesex marriage was legalized in [06:31] the US and Windows 10 was released as [06:34] well. So, a lot has changed in the world [06:36] since then, yet a lot also hasn't. Um so [06:41] today we're going to be covering some [06:43] really practical um experiences from our [06:46] panelists. We're going to be hearing [06:47] some fantastic tips and advice for you [06:49] to hopefully take back to all of your [06:51] teams. Um but first we wanted to sort of [06:54] sense check that everybody's on the same [06:56] page on the topic. So we're just going [06:59] to start by um talking through and [07:01] Reggie hopefully you can uh talk through [07:04] this with us about what we mean by [07:06] software uh software maintenance. Why [07:10] are we here talking about it? Why should [07:12] people care about it? I know that we've [07:13] heard a little bit in the intros. Um, [07:15] but yeah, let's let's get that [07:17] definition out there. What do we mean by [07:18] software maintenance? [07:21] >> Absolutely. I think typically like the [07:24] way I like to describe to my teams is I [07:26] like to look at software applications [07:28] like a home, right? It may take you [07:31] three months, four months, six months to [07:33] build a home, but you may be living in a [07:35] home for the next 30, 40, 50 years, [07:37] right? Are you going to build memories? [07:38] All of these things are going to happen [07:39] in this home. And a lot of people get so [07:41] caught up in the build that a lot of [07:43] people forget about the actual [07:44] maintenance and the overhead that comes [07:46] with the home. It's going to be light [07:47] bulbs that need to be changed. We got to [07:50] uh change out the air filters. We got to [07:52] mow the grass. We got to do all of these [07:54] things. And those little things over [07:56] time add up a lot. And so I think uh far [08:00] too often um our mental models have not [08:02] necessarily updated to kind of recognize [08:05] software as that. we just think we can [08:07] keep building and building and building [08:09] on to it, but if the home starts off as [08:11] a as a one-story home and then you add [08:13] two more stories, can't be surprised [08:15] when you have foundation issues in a [08:17] couple of years. And so I think as a [08:20] result, um I think a lot of times things [08:22] have moved so fast and we focus so much [08:25] on like let's let's introduce new [08:27] features, let's do all the nice cool [08:29] things that everybody's doing that a lot [08:31] of times we overlook the maintenance. [08:33] And so, uh, I think it's extremely [08:35] important, especially now that we're [08:36] moving as fast as we are with AI being [08:38] introduced into the mix. It's extremely [08:41] important to really talk about [08:43] maintenance and actually have uh [08:45] procedures and structures and standards [08:47] around it because at the end of the day, [08:50] your leaders or your CTO's or whoever, [08:52] nobody's going to go and say, "Well, I'm [08:54] blaming the AI." They're going to look [08:55] at you, you know, they're going to look [08:56] at the person that that merged that PR [08:58] in, that that brought that code in, all [09:00] of that kind of stuff. And so now more [09:02] than ever, I think operations and and [09:04] just the the maintenance overhead that [09:06] comes with building software, I think [09:08] it's is it's is more important than ever [09:10] to talk about these types of things. [09:13] >> I'm really trying hard not to make the [09:15] snarky comment at the moment about the [09:17] leaders blaming AI, which is kind of in [09:19] the news at the moment. Um but I will uh [09:22] resist from that. Um but yeah, [09:25] fantastic. Thank you. And I think that [09:27] um that that kind of investment and [09:29] knowing how to talk to your senior [09:31] leaders, knowing how to kind of sell the [09:33] value of that as well is super super [09:35] important. And I think that's something [09:37] that that we'll likely um touch on a [09:39] little bit. Um but I'm also really [09:42] hoping that we can um set the scene a [09:45] little bit. um Hila, I'll pass over to [09:46] you in a sec of and we've got this this [09:50] title of software maintenance being [09:52] stuck in 2015, but I'd love to hear a [09:54] little bit of more about um the aspects [09:56] of maintenance that you feel have [09:59] changed over the years. Where are those [10:01] trends? What what has differed? Um and [10:04] where are the bits that haven't? Those [10:05] are the bits that we we're sort of [10:07] obviously talking about a little bit [10:09] where everybody's getting stuck. Um but [10:11] what have you seen change and and what [10:12] have you felt has stayed the same since [10:14] around then? [10:16] >> So I would leave the the core parts to [10:19] people that actually did development [10:21] here. I will currently focus on the [10:23] peripheral which is still very very [10:25] important. For example security okay all [10:28] of the vulnerabilities that developers [10:30] don't like to deal with and they [10:33] introduce packages and in the [10:34] requirements they uh use a specific [10:37] package. But what if they there is a CVE [10:40] or what is there any vulnerability that [10:42] they need to address? It's the job of [10:44] the DevOps engineers to incorporate um [10:47] scanning tools in the CI/CD and if [10:49] something happens then we will tell the [10:51] developers and maybe they will fix it [10:53] maybe not and then that's a hideous part [10:56] to get to production in a state where we [10:58] are not sure what do we have false [11:00] positives yes no so all of the the topic [11:02] of security vulnerabilities is something [11:04] that I think got addressed very well um [11:09] in the in the upcoming years after 2015 [11:12] uh some tools better than others to to [11:16] address false positives to help [11:18] developers deal with it before getting [11:20] to production before not getting to a [11:22] place where it um blocks any deployments [11:27] to production for example. So all of the [11:29] this thing is very important and usually [11:32] developers don't like to to deal with [11:34] it. They just want to write code and [11:36] that's it. But security vulnerabilities [11:37] is something that is part of the the [11:39] day-to-day and nobody can really ignore [11:41] that. So I would say this is one thing [11:44] that I personally as a develops engineer [11:47] uh um dealt with it. Other aspects are [11:52] um whether developers understand or [11:56] would like to take that the fact that [11:58] software [11:59] maintenance is al is only the software [12:01] development only their code or also the [12:04] other parts like CI/CD some developers [12:06] say no no devops and should do it and [12:08] that's it and some developments say no [12:10] I'm building the image I'm building the [12:13] all the dependencies I should be the one [12:15] to handle also the deployment to dev and [12:18] and then production Yeah. So, this also [12:21] got addressed. Not quite as good as I [12:25] would have hoped because it's still a [12:26] matter of culture and perspective, but [12:30] it is at least something that was [12:32] addressed. And um yeah, so that's the [12:37] peripheral stuff that I got to [12:38] personally uh um tackle, but I will I [12:42] think we'll go to AB to to discuss the [12:45] hardcore parts of software maintenance. [12:48] maybe I'll jump in and add my take on [12:50] this one. So I I'll start by what has [12:53] changed. So I feel like even before the [12:56] AI uh revolution or the era that we are [12:59] seeing right now, the surface area [13:02] exploded. Okay, much more microservices, [13:05] dependencies, manage platform, the [13:08] release velocity was much higher even [13:11] before the AI if we compare it to 10 [13:14] years ago. So everything has changed [13:17] cloud SAS open source change [13:20] continuously and it's not something that [13:22] we're managing. So it's someone's else's [13:25] code running in our production systems [13:27] and all these moving parts and all these [13:29] interconnections is something that [13:31] someone needs to be in charge of. Um [13:35] what has changed also I guess our [13:39] expectations from different uh owners uh [13:44] the code owners or the the the devops of [13:46] platform engineering teams the rise of [13:48] IDPs all these things changed what [13:51] hasn't changed and this is the reason we [13:53] are here today is the fact that software [13:56] maintenance is still reactive and we are [13:58] only dealing with it when it's too late [14:00] or something is burning or there is like [14:04] a a huge shout from someone in the [14:07] organization saying we must deal with it [14:09] right now because something is about to [14:11] happen or already happened. It's still [14:14] ticket driven uh instead of I'll say [14:17] risk driven or part of the business [14:20] decisions. Um and [14:24] yeah and if I'm adding AI to everything [14:27] I'll say that AI has changed the way we [14:31] write code. So now we write code 10 [14:34] times more than before or even more. Uh [14:38] but what hasn't changed is our capacity [14:41] to maintain this code. So AI is not [14:43] working as well uh in maintaining on or [14:47] having the full context of what's going [14:49] on as it works when it's generating [14:53] generating new code. And that's one of [14:55] the biggest problem we need to solve [14:56] right now because uh the the gap between [15:01] the velocity or frequency of changes to [15:04] what we can actually maintain and uh you [15:07] know invest in keeping things running [15:10] that that's the big the biggest issue [15:12] that we have today. Um yeah I guess that [15:16] that's my take on this one. [15:19] Thank you. And I would love to go over [15:21] to to AB. Um AB, welcome again. I know [15:27] that you've experienced some some pain [15:29] points. Uh might have some great [15:30] examples to share with the audience [15:32] today. So could you talk us through um [15:34] maybe you know what the biggest pain [15:36] points you have experienced in the area [15:38] of kind of software maintenance are? [15:40] >> All right. Um, as it regards pain [15:42] points, I would say that two stand out [15:44] for me. And the first one is something [15:46] everybody whines about every time. Tech [15:49] debt. But the funny thing about tech [15:52] debt is we often define it as a [15:54] conscious decision to take a nonoptimal [15:58] path to achieve a goal in the short [16:00] term. However, majority of the tech that [16:03] you see, they weren't conscious [16:05] decisions. [16:07] They are just bad code and poor designs [16:10] that could have been written differently [16:12] from day one. And this causes like two [16:15] major problems. Let's start with the bad [16:18] code. First of all, that spreads in some [16:20] cases. New journals come in, they assume [16:23] it's the standard and then they [16:25] propagate it. Before you know, in a [16:28] situation where there's no culture of [16:30] keeping track of tech debt or areas that [16:32] need some rework, you just notice that [16:34] things start getting worse and [16:37] it's more difficult to maintain [16:40] something the more you postpone it. I [16:42] like the um the analogy that Reggie used [16:46] about a home. It's like when people are [16:48] building, they're focused more on the [16:50] building. They don't think about the [16:51] fact that this might be a bungalow now [16:54] but maybe we want to make it a duplex [16:56] later or this may be a one story now but [16:59] maybe want to make it two stories later. [17:01] It's just about what's the requirement [17:03] now and then they work with that and [17:06] then it becomes really hard to maintain [17:08] the code. The second thing is even when [17:11] tech debt is intentional [17:15] we never really get back to it. I have [17:18] seen to-dos that are 3 years old and I [17:21] had to personally ask like is there [17:23] anyone planning to actually do this [17:25] thing because this to-do thing here is [17:28] like 3 years old. So we never get back [17:31] to it and um many times because things [17:35] currently work and we have no push to [17:37] rework them or keep the system [17:39] maintained. We wait till there's a [17:42] breakage in the system or there's a huge [17:44] bottleneck and then that's when we [17:46] realize as Tal said we're more reactive [17:50] as opposed to proactive. [17:52] The second pain point would be something [17:54] that I would say Hila is very passionate [17:57] about and that's documentation. [18:00] Software is incredibly hard to maintain [18:03] when you do not have the slightest idea [18:05] why it was built the way it was. someone [18:08] could make a small change and you think [18:10] it's totally unrelated and you're like [18:12] maybe everyone says production is down [18:14] and you're like can't be me what I did [18:16] is totally unrelated and it was you [18:19] >> can I use reactions I want to use [18:21] reactions and put you some a lot of [18:22] confetti please [18:25] so on I mean oh my god [18:28] >> but that's because there's no like there [18:31] are no docs and the thing is people [18:33] think of docs as this huge page [18:36] documentation can ring anything from [18:39] comments in your code to say maybe don't [18:42] touch this part because it's related to [18:44] this other part or something that can [18:46] help people understand how things work. [18:48] They can be RFC's erds but in whatever [18:50] come they in in whatever form they come [18:53] in it's um they totally make software [18:57] maintenance easy and and this is an area [19:00] I've seen a lot of teams struggle in or [19:04] struggle with. Something I would say is [19:06] that these pain points become very [19:08] obvious when you find it difficult as a [19:11] team to adapt to changing requirements [19:14] and you'd see that when product comes in [19:17] and says oh we just need to make this [19:19] small change and engineering it's like [19:21] that must be easy and then you go touch [19:24] the code and you then realize that the [19:26] system was not built to be extended and [19:28] it hasn't been properly maintained and [19:30] suddenly a small change leads into a [19:32] bigger project but that's because we [19:35] didn't do the right thing in the first [19:36] place. So yeah, those are the two main [19:39] pain points I have experienced. [19:41] >> Fantastic. Thank you. Uh well, not [19:44] fantastic that you've experienced them, [19:45] but I think it is, you know, the [19:47] reaction you've got here in the in the [19:49] group I think is probably reflective of [19:51] how people are are feeling outside as [19:53] well. Um I would really love to hear [19:56] from Reggie on this because you've [19:57] talked about a lot of things there that [20:00] are kind of baked into the culture. So [20:02] standards juniors coming in feeling like [20:04] okay this is the standard that we we [20:06] need to align with. Um so Reggie how um [20:10] how would you describe the the key [20:13] cultural drivers that really contribute [20:16] to a successful culture uh of [20:19] maintenance software ownership all of [20:21] all of that good stuff. Um if we're [20:23] going to flip it around we've heard [20:25] about the pain points. What does a great [20:27] culture look like? What should people be [20:28] doing in a practical level um to turn [20:31] that culture around or to to get to a [20:33] place that they they aspire to? [20:35] >> Absolutely. I love this question. Um [20:37] it's funny. It we had an incident the [20:39] other day at work and um I had a [20:42] conversation with a manager and I told [20:44] him, you know, we're a startup. We, you [20:46] know, we're figuring things out and uh [20:48] one thing I was telling him I'm like, [20:49] you know, I believe in a blameless [20:51] culture, right? But I also believe [20:53] believe in a accountable culture, right? [20:56] I think a lot of times people just say, [20:59] "Oh, well, it's blameless." Like, we [21:00] don't blame people. But you have to take [21:01] accountability, especially from [21:03] leadership, right? Because to the point [21:05] that AB was making, those juniors, [21:07] those, it ain't necessarily got to be a [21:09] junior. It could be just a person that's [21:10] on board into the company. They're [21:12] coming in and they're looking at the [21:14] code base and they're going to follow [21:15] the patterns that are already laid in [21:16] front of them. And if and if and if [21:19] people aren't able to be able to go to [21:22] the people that have written the code [21:23] and do all of the things and talk about, [21:25] hey, why we make this decision or what [21:27] we doing here and all of that kind of [21:28] stuff, then what is going to happen is [21:30] it's like now this person is going to [21:31] create a brand new mental model of what [21:33] they should be doing and they're not [21:35] necessarily following the patterns, [21:37] right, that maybe leadership believes [21:39] that they should be following. Which [21:40] leads me into my other point, which is [21:42] the other part about making a great [21:44] culture is discipline. You have to have [21:46] discipline on a leadership level. And so [21:49] even if that means as a senior engineer, [21:51] I know I don't like writing [21:52] documentation and well that's not [21:54] necessarily me. I love writing [21:54] documentation. But even if I don't like [21:56] writing documentations or I don't like [21:58] doing ADRs or I don't like scoping out [22:00] my projects or whatever it is, you have [22:02] to do it because this is the road map. [22:05] This is the blueprint that everybody [22:06] else is going to follow. Not just over [22:08] the next three months, but really for [22:09] years to come. Because typically once [22:11] that code goes out as AB said like you [22:14] might intentionally introduce tech debt [22:16] into your environment but the reality is [22:18] is that you may not get back to it 6 [22:21] months a year you may never get back to [22:23] it. So at the very least it's important [22:25] to have strong discipline around areas [22:28] when it really when it comes to [22:29] communication communicating all of these [22:31] different ideas having diagrams having [22:34] docs leaving comments in the code [22:36] because you don't know the learning [22:38] style or the way that people are going [22:40] to be looking at the code and the [22:41] environment when they walk into your [22:43] when they walk into your environment. [22:44] And so it's important to have really [22:46] really strong discipline um when it [22:48] comes to these areas because if not then [22:50] people are going to go off like people [22:52] gonna go off and start building all [22:53] these mental models and then the [22:55] maintenance becomes even harder because [22:56] you got a team of seven or eight people [22:59] and you got four or five different [23:01] mental models around the business domain [23:03] and that's extremely difficult to manage [23:06] over a course of time. [23:10] >> Let me just say something there. Let me [23:12] just add something about the whole drive [23:15] for culture. I noticed that some people [23:18] do feel that if I report something that [23:20] means I'm the owner and so they refrain [23:24] from actually doing that you you [23:26] encounter tech debt. you find that this [23:30] isn't right but instead of saying oh [23:33] this isn't right we should change it [23:34] you're scared that if I say that then I [23:37] have unintentionally availed myself as [23:39] the owner or the person who has to [23:41] change this and so they actually do [23:44] nothing so I agree that we should have a [23:46] culture of logging things to say okay or [23:48] tracking tech there to say I found this [23:51] thing this is this is what I think it is [23:53] this is how I think we should evolve it [23:56] and just keep it there so we have that [23:57] visibility [23:58] And then we can begin to think about how [24:00] we want to tackle things [24:05] >> completely. [24:05] >> Absolutely. [24:07] >> Reggie, I just wanted to follow up on [24:08] your point um for my clarification, but [24:12] also it might be an interesting point as [24:14] well of you talked then about [24:15] accountability uh and leadership [24:18] accountability as well. My take is um [24:22] that I'm interpreting that to mean kind [24:24] of leadership uh of all levels. Is that [24:28] kind of what you mean? Do you mean that [24:30] there should be accountability [24:31] throughout the org or you [24:34] >> Yeah. [24:34] >> No, absolutely. It got to be throughout [24:36] the org because like when we talk about [24:38] culture, it's engineering culture. It's [24:40] not the culture of a team. Yeah. [24:42] Obviously, your team may have your own [24:43] culture, but at the end of the day, you [24:44] all work for a business and the business [24:47] has these objectives that they're trying [24:48] to drive towards. So it has to be the [24:50] culture around the engineering. I think [24:52] that's something that that can be very [24:53] difficult especially as you scale out a [24:55] lot and I know we had a lot of issue [24:57] like this when we were at when I was at [24:59] elastic because you know you got people [25:01] across different parts of the world and [25:03] they all have different mental models of [25:05] what's going on. So, it's extremely [25:07] important for leadership on every level [25:10] to really embody these ideas culturally [25:13] around the engineering culture that we [25:14] want to build because if not, you're [25:16] going to have people coming in being [25:17] like, "Oh, well, y'all y'all aren't [25:18] doing this. Well, we did this at my last [25:20] company." Then they're gonna come in and [25:21] try to do their own thing and all this [25:22] kind of stuff and they might not [25:24] necessarily be the culture that they're [25:25] trying to develop there. [25:28] >> Great. Thank you for clarifying. I just [25:30] wanted to I know that that's a whole [25:32] topic in itself kind of like what is [25:34] leadership? what level, you know, does [25:35] leadership kind of kick in as a an [25:37] attribute? Um, so yeah, I think that's a [25:40] super super important point when you're [25:41] trying to build out the culture. Um, but [25:44] kind of moving, not moving away from [25:46] people, um, but thinking less about [25:49] individuals and more about tooling. [25:52] Hila, I know that you've got some loads [25:55] of experience and some really great [25:56] opinions uh, around AI, particularly [25:59] when it comes to software maintenance. [26:00] So I'd like to ask how you see the [26:03] balance of maintenance responsibilities [26:06] playing out between humans and AI [26:08] particularly as more and more companies [26:10] more and more teams adopt um the the [26:13] tools that we're seeing is so common [26:14] place nowadays. [26:16] >> So the the term vibe coding emerged and [26:20] everybody got excited about it but it's [26:23] good for dev. It's good for prototypes. [26:25] It doesn't good it's not good for [26:26] production. So I think that once I hope [26:31] people will understand that it it's good [26:34] until a certain point that's it but we [26:36] can see now tools emerging understanding [26:39] that so basically taking AI and uh [26:43] having the built-in notion of not [26:48] vibe coding but how I call it or AWS [26:51] call it specdriven development to use AI [26:55] but in a very methodological I hate this [26:58] word methodologic [27:01] I think way of doing things of of [27:04] developing um a feature for example. So [27:08] again I didn't mean to do a shame [27:10] shameless plug but here it is very short [27:12] kirao our IDE it is it has built-in [27:16] specdriven development and why is it is [27:18] so important because it forces the the [27:20] developer to work in a certain way. So [27:22] once you say in a natural language I [27:25] want to build a feature or I want to add [27:27] a feature to my [27:29] product that does ABC then the ID [27:33] automatically says okay cool I'm going [27:34] to build a spec that introduce the [27:37] requirements you need to go over it see [27:39] if it makes sense if this is what you [27:41] meant has um aligning to the user [27:44] stories to see that this is something [27:46] that you actually want to do and [27:48] understand why then to the design and [27:50] then to the actual tasks And that way [27:52] because if you don't do that not all [27:55] developers will do it themselves like [27:57] okay let's work method you know in a in [27:59] a very organized way let's do it you [28:01] have to have a very built-in mechanism [28:04] to make developers do it and then once [28:07] you have it you AI is is fully at your [28:10] disposal you can do whatever you want [28:12] with it it it does everything it you can [28:15] al also leverage uh agents to do h to [28:19] handle a lot of the tech that in the [28:21] background while work on in the ID. So [28:23] this is awesome assuming that it [28:26] leverages this uh approach because that [28:29] way you can um take the full power of AI [28:32] but in a somewhat constraint way that [28:35] will help you create better and quality [28:38] and more quality uh u products and and [28:41] and features to your production [28:43] environment. So AI is great, but you [28:46] need to make sure it follows a certain [28:48] um methodology to make sure that you [28:51] actually create something that is [28:52] worthwhile to use. [28:56] >> Okay. I didn't know whether we'd have [28:58] any other people trying to jump in on [29:00] that one. [29:01] >> Yeah, I can. I have my opinion. So you [29:03] know I'm a bit biased of course building [29:06] a tool solving tech that and and [29:09] software maintenance friction but I I [29:11] will try to reframe [29:13] uh the work or or what we're trying to [29:16] do here and say that you know I [29:18] mentioned before that what has changed [29:21] the surface and now we have a lot of [29:24] open source tools and third party [29:26] vendors and managed services and cloud [29:28] providers and each one of them comes [29:31] with a life cycle or or a end of life [29:36] timeline. So if you're leveraging I [29:38] don't know RDS or Kubernetes or whatever [29:41] technology it is in any cloud provider [29:45] it comes with a clock and the moment you [29:48] started using it you need to plan ahead [29:51] the next upgrade and it's never a [29:53] vanilla upgrade. So you want to upgrade [29:55] your uh I don't know posgress or open [29:58] search or uh MongoDB database. So the [30:03] data the database team or the devops [30:05] team are in charge of the actual change [30:08] of the database but the development team [30:12] needs to understand the breaking changes [30:14] the change of behavior uh all the bug [30:17] bugs introduced or fixed in the next [30:19] version and all this work [30:22] they can't solve it because it's a black [30:24] box and a black box someone is managing [30:26] a technology not you are not the subject [30:29] owner expert and you also cannot not uh [30:32] folk this technology to fix something. [30:35] You are dependent on someone else to do [30:37] the job and you are dependent on [30:39] understanding how it affects you and [30:41] what you need to do in order to keep [30:43] your business running. So I guess what [30:46] is missing is first of all uh visibility [30:50] to the entire tech stack the different [30:53] layers of the tech stack because it's [30:54] not just infrastructure not just code [30:57] not just runtimes or operating system [30:59] it's it's a whole uh and the second [31:01] thing is a shared language so you [31:04] mentioned it before I think Reggie when [31:05] you spoke about leadership and the [31:08] organization needs to speak the same [31:10] language uh and in security they were [31:13] able to do it And you know everything is [31:15] about risk and you have critical and [31:17] high and medium and low and then you [31:20] it's easy to to you know get a CV score [31:23] it some way and then you have an SLA to [31:25] deal with it. That's something that [31:27] security teams did very well uh in order [31:31] to react to something that is not under [31:33] their control. Um we need to find the [31:36] same language uh and to find a way to [31:39] make maintenance and routine maintenance [31:42] and uh something boring again not [31:45] something that all all the organization [31:47] like all ends on deck because it's about [31:50] to break production how we can be [31:52] predictive and be proactive and take all [31:55] the friction and maintenance toil that I [31:57] just mentioned you know someone is [31:59] getting this message saying uh this [32:01] database needs to be updated by this [32:04] eight, but then you start the meetings, [32:06] right? You have a meeting with the [32:08] leadership and you say, "Hey, we don't [32:10] know how it affects us. Let's schedule [32:12] some time in the next sprint to do some [32:13] research pre, you know, two weeks later, [32:16] the next sprint. Okay, now we need to [32:19] prioritize it. Is it important enough? [32:21] Not different teams need different [32:23] changes. For some, it will be uh you [32:26] know a a green green field just upgrade, [32:29] nothing will break. For others, it's a [32:31] refactor of the entire codebase." So all [32:34] these main you know I'll say manual [32:38] frustrating work that no one comes to [32:40] job and say hey I'm excited about [32:42] researching how MongoDB broke my [32:45] production today. No one does this. So [32:48] it it's something that we need to find [32:49] the right tools and or the right uh [32:53] methodologies to solve. Um so so that's [32:57] the biggest opportunity I feel uh we can [33:00] introduce right now to this area. and of [33:02] course leveraging AI to do most of of [33:05] the parts. [33:06] >> I think I've actually been really lucky [33:08] in that I've worked with a lot of [33:10] engineers I think relatively speaking [33:12] who really enjoy that kind of work and [33:15] who are super proactive and take great [33:16] ownership. So I know I'm probably the [33:19] exception. Um but yeah that's that's I [33:22] think a really really great way to look [33:23] at it. Um so um yeah thank you for [33:27] sharing that. Um, are there any other [33:30] opportunities tal that uh that you [33:32] haven't covered? Because I know that we [33:34] were thinking about AI, but are there [33:35] any other kind of really really great [33:37] opportunities that people should be open [33:39] to thinking about or do you do you feel [33:40] like you you touched on everything [33:42] there? No, I feel like people should [33:45] start talking about a system of record [33:48] of software maintenance, a way to manage [33:50] it as a first class citizen and not just [33:53] something that uh you know it's reactive [33:55] and we deal with it when we have a fire [33:58] that we need to firefight. Um and we [34:00] also need a system of record uh to find [34:03] a way to reduce the manual work and [34:07] repetitive repetitive work that we are [34:09] doing in this areas. So I guess I kind [34:11] of talked about it before but but we [34:15] need to structure it in a way and you [34:18] see that Gartner is trying to come with [34:19] some methodologies to how uh you know to [34:23] to prioritize and and fit different [34:27] initiatives into boxes. Uh and we see a [34:30] lot of conversation in this area. It's [34:32] really one of the emerging trends uh now [34:35] with AI of course uh because it just [34:37] amplifies the problem and people meet it [34:41] in production much uh more more often. [34:45] Uh but yeah, this is the one thing that [34:48] I I will do tomorrow morning if I don't [34:51] have a systematic approach right now [34:53] that that's the one thing I'll do [34:55] tomorrow. [34:56] >> Thank you. Thank you. Uh just a quick [34:59] reminder to people watching if you want [35:02] to ask any questions to the panelists. [35:04] We may have a little tiny bit of time. [35:06] Um we'll see. Thank you to the person [35:08] who's literally just sent one in. So we [35:10] may not have as much time now. Um but if [35:12] you do want to send in any questions [35:14] then we'll either try and answer them [35:15] live um on the call itself or we will [35:18] jump over to the Slack channel um on the [35:21] lead dev Slack to answer those [35:22] afterwards. Um but we'll sort of we'll [35:25] move towards the the tail end of this. [35:27] So AB, I would really love to get your [35:30] thoughts. So um we've heard a little bit [35:32] from TAL in terms of opportunities and [35:34] recommendations, but do you have any [35:36] advice to people who are looking to [35:38] improve their software maintenance right [35:41] now? So what practically should they be [35:44] taking back to their teams after [35:45] watching here today? That's a very [35:48] interesting one. I would say that it's a [35:52] it's kind of a combination of what [35:54] everyone has said. First of all, culture [35:55] is important. It's important to begin to [35:59] build a culture where people don't see [36:01] maintenance as an afterthought or [36:04] something that we do after we ship. No, [36:06] you need to begin to think about it as [36:08] from the first line of code the [36:10] maintenance begins. So, we need to start [36:12] to ship what's maintainable and what's [36:15] extendable. The second thing is [36:17] something I feel a lot of people [36:18] struggle with and that's automation. [36:22] AI is here to stay whether we like it or [36:24] not. We're in the AI era. So, um we you [36:29] should try to automate as much as [36:31] possible. However, we have tools that [36:35] are built for this. So, as much as you [36:37] can automate um tasks that are boring, [36:43] but we know that should actually happen, [36:45] let's try to use tools that are built [36:47] for that to do those. And the next thing [36:49] will be understanding the business and [36:52] the environment. Some people make a case [36:55] for maintenance to their um maybe senior [36:59] their um senior leadership and they say [37:03] um things are not moving fast enough [37:05] because we're not doing the right things [37:07] but then they actually comfortable with [37:09] the speed. So that's not a good case for [37:12] the business. So you need to understand [37:14] the business so that you can make a good [37:16] case for it I would say. [37:20] Well, that actually leads really nicely [37:22] into one of the the questions that's [37:24] been asked in the Q&A feature. Um, and [37:27] I'll just uh read that out quickly, [37:29] which is what are ways that engineering [37:32] leaders can quickly pitch proactive [37:34] maintenance activities to product [37:36] owners, business owners, and other [37:39] non-technical stakeholders in their [37:40] organization. Put another way, how can [37:43] we avoid the project management overhead [37:46] of maintenance killing proactive [37:48] maintenance drive from engineers? Uh, [37:50] and I'll actually just paste that in the [37:52] chat so that our panelists can read and [37:54] absorb that if they uh can't see it. [37:56] Anybody wants to share any opinions on [37:59] that one? [38:00] >> Yeah, I I can I'll share what I did, you [38:03] know, in previous companies. uh I just [38:06] tried to create a shared language you [38:09] know when when things actually got [38:13] prioritized when there was a deadline [38:15] right when you say it's not something we [38:18] should do we can't not do it by this [38:21] date because this will be the business [38:23] impact um but you don't want to use this [38:26] pure mechanism all the time right so you [38:29] need to find a better way to frame [38:31] what's important to the business and [38:33] then say Hey uh first of all [38:38] I I'll stop for a second and say some [38:39] organization if you ask them they will [38:41] say that they have a bucket of 20 40 60% [38:45] of their uh quarterly uh I'll say bucket [38:50] to software maintenance and keep the [38:52] lights on. So that that's a a common [38:55] practice and it happens because they [38:57] don't know what will happen but they had [38:59] enough issues before to to understand [39:02] that something will pop up. So being [39:05] proactive is not just saying uh we will [39:08] keep this time aside for the next outage [39:11] to come or the next problem to come is [39:13] to be more uh proactive about it and say [39:17] hey this is the things that we already [39:19] identified for the next 6 months or 9 [39:21] months that we must deal with. Um here's [39:24] why we believe we must deal with it. [39:27] This is the business impact. This is how [39:28] it affects our ability to deliver new [39:31] features. Here's how it prevents us. Uh, [39:35] you know, here's the SLA breach. Here is [39:38] the uh I don't know the the the vendor [39:43] sunsetting something. All this [39:45] information if you get it in advance, it [39:48] kind of solves the discussion of uh to [39:52] try and convince people and do all these [39:55] roundts around uh the project management [39:58] side of things. So, so we all now speak [40:01] the same language and we understand why [40:03] it's important, why should I care and [40:06] why it sits under my roles and [40:08] responsibilities or under my ownership [40:11] and you can go ahead from pitching to [40:15] actually reasoning uh in a much higher [40:20] uh layer. So most of the time what I did [40:22] before I had this kind of mechanism I [40:25] tried to tie up uh my initiatives or the [40:28] things that I wanted to uh achieve in [40:31] this quarter or the next quarter with [40:33] the company OKRs. So a and it's kind of [40:36] what I'm doing right now as a CEO uh you [40:39] know selling to companies I'm trying to [40:41] understand what are the top priorities [40:43] they have whether it's leveraging AI to [40:47] you know release engineering capacity or [40:50] preventing outages or just reduce the [40:53] the manual work they're doing and then I [40:55] I try and translate what draft is doing [40:58] to the same uh objectives. So if you'll [41:02] be able to speak the same language the [41:04] business talks, that's the major step [41:06] you'll take forward in in changing the [41:09] way the culture of the organization [41:11] work. I hope I was able to answer this [41:13] one. [41:14] >> I want to add something to that really [41:15] quickly and that's because the question [41:18] says how can we quickly pitch right? So [41:21] it's like how can I just quickly put [41:23] that in there? And two things I would [41:26] say uh I always ask how fast do you want [41:29] to move and how effective do you want [41:31] your software to be? That's the fastest [41:33] way to just pitch it. So how fast do you [41:35] intend to move? Oh, we would like to um [41:38] ship seven features in seven weeks. [41:40] Okay, if you want to do that then these [41:42] are the things we have to do proactively [41:44] to enable the team to do that. How [41:46] effective do you want software to be? [41:48] Oh, I want um a lower latency. I want [41:51] this or that. So it's like as he said, [41:53] tie it to the business outcomes and [41:56] objectives and every business loves to [41:58] move fast. Every business wants to make [42:00] money. So yeah, if you can frame it that [42:02] way, that's a way to quickly pitch it. [42:06] >> Fantastic. [42:06] >> Not only that, it's just the fact that [42:08] if you find the reasoning for that [42:10] proactive work, how it will affect them, [42:13] then that's it. You're done. [42:16] >> Yeah. I I think and I just just to [42:18] piggyback on that like one thing that I [42:20] I find um we kind of sometimes as [42:24] engineers we fall short on is like we [42:26] always have our engineering hat on but [42:28] we don't never put our business hat on, [42:30] right? Or we don't put our finance hat [42:31] on. And a lot of times when we got to go [42:33] and talk to executives, they're not just [42:35] thinking about the X's and O's, right? [42:37] They're talking about the dollar signs, [42:39] the commas, and the decimals. And so as [42:41] a result, like I think that's a muscle [42:43] that does have to be worked. Like we got [42:45] to get out of the mindset of like oh [42:46] okay like we going to ship code in a [42:48] week two weeks. No like put your [42:50] business mind on. You know what I'm [42:51] saying? Put your business hat on and [42:52] think from the f from the reference of [42:54] the business because it becomes a lot [42:55] easier to communicate to your leaders [42:57] when you're speaking their language. You [42:59] can't expect them to come into your [43:00] world. You kind of got to step into [43:01] theirs. [43:05] >> So unfortunately we've only got a couple [43:08] of minutes left. Um, we do have some um [43:11] some questions that have come in um with [43:13] the um with the Q&A feature. Um Reggie, [43:17] thank you also for tapping away in the [43:19] background and kind of asking answering [43:21] some of those async. So, appreciate your [43:23] work there. Um I just did want to kind [43:25] of draw us to a close for the the live [43:27] stream though. Uh it's been a great [43:29] discussion. I've really enjoyed hearing [43:31] from all of you. I hope that everybody [43:33] watching has really enjoyed it too. And [43:35] some of the notes that I've been [43:36] scribbling down are just about the the [43:38] importance of culture. Um from AB you I [43:42] believe said uh maintenance starts from [43:44] the first line of code and we talked a [43:47] bit about how the balance between kind [43:49] of proactive and reactive maintenance is [43:51] very different and can lead to to very [43:52] different outcomes. Thinking about the [43:54] automation, thinking about um automating [43:57] the boring tasks, using appropriate [43:59] tools of which there are a lot out [44:01] there. Um, and also I love the the [44:04] analogy of the house. Um, I'm I often [44:06] think about it in terms of like [44:07] gardening, but I love that point about [44:10] it's a bungalow now, but where might it [44:12] go into the future? What's the [44:13] potential? Um, I I also write down the [44:17] fact that everything comes with a clock. [44:19] Um, and that we we need to put our [44:21] business hat on as well. Um, something [44:23] that I am similarly guilty sometimes of [44:26] not doing enough. Um, so I just wanted [44:28] to thank all of you again for all of the [44:30] amazing insights. Just to uh reiterate [44:33] in terms of anybody who hasn't had a [44:34] question answered yet, we're going to go [44:36] over to the lead dev slack um in the [44:39] panel Q&A channel hyphenated. So if you [44:43] want to come and continue the [44:45] discussion, we're all going to head over [44:46] there now. And if you're not signed up [44:48] already, you can get there by going to [44:49] leaddev.com [44:51] hyphen u leadv.com/joinhyenlack. [44:56] So, thank you so much again for joining [44:58] us today and we hope to see you again [45:00] next time. Bye. [45:03] >> Bye.  [[3. Resources/Readwise/Full Document Contents/Articles/Why Software Maintenance Is Stuck in 2015|Full Document Contents]] ## Document Notes --- tags: #software-maintenance #tech-debt #devops #engineering-culture #ai-coding author: Lead Dev source: YouTube reference: https://www.youtube.com/watch?v=gMn6JkLDaGc date created: 2024-01-15 10:30 --- # 🏷️ Title: Why Software Maintenance is Stuck in 2015 ## 🧰 Action Inbox - [H1] Establish systematic maintenance record — create first-class citizen system #culture - [H2] Implement spec-driven AI development — prevent vibe coding in production #ai-tools - [H3] Create shared maintenance language — tie initiatives to business OKRs #communication ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Lead Dev Slack Community](https://leaddev.com/joinslack) - [Draft Platform](https://draft.dev) ## 📝 Summary - Expert panel discusses why software maintenance practices haven't evolved since 2015 despite massive changes in development velocity - Core problems: reactive approach, lack of systematic maintenance records, cultural issues around ownership and documentation - AI has accelerated code writing 10x but hasn't improved maintenance capacity, creating dangerous gaps - Solutions focus on culture change, automation of boring tasks, and speaking business language when pitching maintenance work - Key insight: maintenance must be treated as first-class citizen from first line of code, not afterthought ## 📖 Main Content The panel identifies a fundamental disconnect: while software development has transformed dramatically since 2015 with microservices, cloud platforms, and AI-assisted coding, maintenance practices remain largely reactive and ticket-driven. The surface area for maintenance has exploded with dependencies on third-party services, each with their own lifecycle and end-of-life timelines, yet organizations still wait for fires before addressing maintenance needs. Technical debt represents a major pain point, often resulting from poor initial decisions rather than conscious trade-offs. Documentation gaps compound the problem, making it difficult to understand why systems were built certain ways. Cultural issues around ownership create situations where people avoid reporting problems for fear of becoming responsible for fixes. AI tools show promise but require disciplined, spec-driven approaches rather than "vibe coding" to produce maintainable production code. The key is creating systematic approaches to maintenance that treat it as a business priority with clear language and metrics that resonate with leadership. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/gMn6JkLDaGc?t=0) — [H1] Panel Introduction and Context - Key idea: Discussion on why software maintenance hasn't evolved since 2015 - Evidence: "2015 was the year that the original Apple Watch released... a lot has changed in the world since then, yet a lot also hasn't" #### ⏱️ [03:15](https://youtu.be/gMn6JkLDaGc?t=195) — [H2] Software as Home Analogy - Key idea: Software applications require ongoing maintenance like homes - Evidence: "It may take you three months to build a home, but you may be living in it for 30-50 years" #### ⏱️ [05:42](https://youtu.be/gMn6JkLDaGc?t=342) — [H3] Security Vulnerabilities Progress - Key idea: Security scanning and CVE management has improved significantly since 2015 - Evidence: "All of the vulnerabilities that developers don't like to deal with... scanning tools in CI/CD" #### ⏱️ [08:30](https://youtu.be/gMn6JkLDaGc?t=510) — [H1] Surface Area Explosion - Key idea: Technical complexity has exploded while maintenance capacity hasn't grown - Evidence: "AI has changed the way we write code... 10 times more than before but what hasn't changed is our capacity to maintain this code" #### ⏱️ [12:15](https://youtu.be/gMn6JkLDaGc?t=735) — [H2] Tech Debt Reality Check - Key idea: Most "tech debt" isn't conscious trade-offs but simply bad code from the start - Evidence: "Majority of tech debt... weren't conscious decisions. They are just bad code and poor designs" #### ⏱️ [15:20](https://youtu.be/gMn6JkLDaGc?t=920) — [H3] Documentation Crisis - Key idea: Lack of documentation makes maintenance extremely difficult and dangerous - Evidence: "Someone could make a small change... production is down and you're like can't be me" #### ⏱️ [18:45](https://youtu.be/gMn6JkLDaGc?t=1125) — [H1] Cultural Accountability Framework - Key idea: Successful maintenance culture requires both blameless and accountable practices - Evidence: "I believe in a blameless culture... But I also believe in an accountable culture" #### ⏱️ [22:10](https://youtu.be/gMn6JkLDaGc?t=1330) — [H2] Leadership Discipline Requirements - Key idea: Senior engineers must model good practices even when they dislike certain tasks - Evidence: "Even if I don't like writing documentation... you have to do it because this is the blueprint" #### ⏱️ [25:33](https://youtu.be/gMn6JkLDaGc?t=1533) — [H3] Ownership Fear Problem - Key idea: People avoid reporting issues due to fear of becoming the owner - Evidence: "Some people feel that if I report something that means I'm the owner and so they refrain" #### ⏱️ [28:15](https://youtu.be/gMn6JkLDaGc?t=1695) — [H2] AI Spec-Driven Development - Key idea: AI coding requires methodological constraints to produce maintainable code - Evidence: "Vibe coding... is good for dev, prototypes. It's not good for production" #### ⏱️ [32:40](https://youtu.be/gMn6JkLDaGc?t=1960) — [H1] Third-Party Lifecycle Management - Key idea: Every technology comes with a clock requiring planned upgrades - Evidence: "If you're leveraging RDS or Kubernetes... it comes with a clock" #### ⏱️ [36:22](https://youtu.be/gMn6JkLDaGc?t=2182) — [H3] Shared Language Need - Key idea: Organizations need common vocabulary for maintenance like security teams have - Evidence: "In security they were able to do it... critical and high and medium and low" #### ⏱️ [39:45](https://youtu.be/gMn6JkLDaGc?t=2385) — [H2] Maintenance as First-Class Citizen - Key idea: Maintenance should be planned from first line of code, not afterthought - Evidence: "Maintenance begins from the first line of code... we need to start to ship what's maintainable" #### ⏱️ [42:18](https://youtu.be/gMn6JkLDaGc?t=2538) — [H1] Business Language Translation - Key idea: Engineering leaders must speak business language to get maintenance buy-in - Evidence: "How fast do you want to move and how effective do you want your software to be?" ## 📚 References - [Lead Dev Community](https://leaddev.com) - [AWS Solutions Architecture](https://aws.amazon.com) - [Draft Agentic Platform](https://draft.dev) - [Kirao IDE](https://kirao.aws) ## 🗣️ Paraphrase - Software maintenance practices haven't evolved since 2015 despite massive changes in development speed and complexity - The core problem is reactive rather than proactive approaches, with organizations waiting for fires instead of preventing them - AI has created a dangerous gap by accelerating code creation without improving maintenance capabilities - Success requires treating maintenance as a first-class business priority with systematic tracking and clear communication ## 📰 Newsletter The software development world has transformed dramatically since 2015—AI assists coding, microservices dominate architectures, and deployment velocity has skyrocketed. Yet maintenance practices remain stubbornly reactive and ad-hoc. This expert panel reveals why: we're writing code 10x faster with AI but haven't improved our capacity to maintain it. The result? Growing technical debt, documentation gaps, and cultural issues where engineers fear reporting problems. The solution isn't just better tools—it's treating maintenance as a first-class citizen from day one. Start by creating systematic maintenance records, implementing spec-driven AI development, and most importantly, learning to speak business language when pitching proactive maintenance work. Resources: [Lead Dev Community](https://leaddev.com), [WordPress Developer Docs](https://developer.wordpress.org/), [WP-CLI Maintenance](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: create maintenance-focused talks demonstrating ROI of proactive approaches - Education: develop workshops on AI-assisted maintenance and spec-driven development - Developer experience: improve documentation standards and maintenance tooling - Community management: facilitate discussions on maintenance culture and best practices #### WordPress - Core: implement systematic tracking of maintenance debt and lifecycle management - Documentation: create maintenance-first documentation standards and templates - Community: develop mentorship programs pairing senior maintainers with newcomers - Training: build curriculum on sustainable development practices and technical debt management - CLI: expand maintenance commands for automated dependency updates and health checks #### Community - Maintainers: establish maintenance office hours and cross-project knowledge sharing - Contributors: create first-issue programs specifically for maintenance tasks - Sponsors: fund dedicated maintenance roles and systematic improvement initiatives ## 🧪 Hypotheses - Organizations treating maintenance as first-class citizen will have 50% fewer production incidents - Teams using spec-driven AI development produce more maintainable code than vibe-coding approaches - Engineers trained in business language get 3x more maintenance initiatives approved - Systematic maintenance tracking reduces emergency firefighting by 40% ### 📊 Methodology - Survey engineering teams on maintenance practices and incident frequency correlation - A/B test spec-driven vs vibe-coding approaches measuring long-term maintainability metrics - Track success rates of maintenance proposals using business vs technical language ### ❓ Questions - How can we measure maintenance debt systematically across different technology stacks? - What specific constraints make AI-generated code more maintainable in production? - How do we scale maintenance culture practices across distributed global teams? ### 🔮 Future Research - Development of standardized maintenance debt scoring systems across platforms - Investigation of AI agents specifically designed for maintenance tasks - Study of maintenance culture patterns in high-performing engineering organizations ### 💡 Implications - Practice: Maintenance must shift from reactive firefighting to proactive systematic management - Policy: Organizations need formal maintenance allocation in quarterly planning (20-60% bucket) - Education: Engineering curricula should include business communication and maintenance planning - Funding: Maintenance roles deserve dedicated funding rather than being treated as overhead ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 12 #### 👀 Visual learners - Present: Panel discussion format, speaker identification - Improve: Architecture diagrams showing maintenance complexity, visual debt tracking dashboards #### 🔊 Aural learners - Present: Full video discussion with multiple expert perspectives - Improve: Timestamped audio clips highlighting key concepts #### 🗣️ Verbal learners - Present: Rich analogies (home ownership, gardening), clear definitions - Improve: Story-driven case studies of maintenance transformations #### 🧩 Kinesthetic learners - Present: Actionable recommendations and practical frameworks - Improve: Interactive maintenance assessment checklists, hands-on workshops #### 🧠 Logical learners - Present: Clear problem-solution frameworks, systematic approaches - Improve: Decision trees for maintenance prioritization, metrics dashboards #### 🧑‍🤝‍🧑 Social learners - Present: Panel discussion format encouraging multiple perspectives - Improve: Community forum discussions, peer review processes for maintenance plans #### 🧘‍♀️ Solitary learners - Present: Comprehensive notes and reflection prompts - Improve: Self-assessment tools for maintenance culture maturity #### 🌿 Naturalistic learners - Present: Ecosystem analogies and lifecycle thinking - Improve: Software ecosystem health metaphors, sustainability frameworks ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, speaker identification - Improve: ARIA landmarks for topic transitions, better alt text for visual elements #### Keyboard navigation - Present: Standard video controls accessible - Improve: Timestamp navigation shortcuts, transcript search functionality #### Contrast and readability - Present: High contrast video player interface - Improve: Transcript formatting with better visual hierarchy #### Media and captions - Present: Full video content with transcript - Improve: Professional captions with speaker identification, downloadable transcript ### 🌍 DEIB Assessment #### Cultural breadth - Present: Diverse panel with different company backgrounds and roles - Improve: Include perspectives from different geographic regions and company sizes #### Inclusive language - Present: Gender-neutral technical language, defined jargon - Improve: Plain language summaries, avoid Silicon Valley idioms #### Representation - Present: Mix of technical roles (CTO, SRE, DevOps, Solutions Architect) - Improve: Include more diverse perspectives on maintenance challenges #### Psychological safety - Present: Blameless culture discussion, accountability without blame - Improve: Explicit discussion of learning from failures ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear cause-effect relationships between maintenance gaps and production issues - Inductive strength: Multiple expert experiences supporting similar conclusions - Analogical strength: Home ownership analogy effectively illustrates maintenance concepts #### Fallacies - Hasty generalization: Some claims about AI coding effects lack quantitative backing - False dichotomy: Framing as either reactive or proactive when hybrid approaches exist #### Tone of voice - Overall tone: Professional but conversational, collaborative problem-solving approach ### 🛡️ DARVO Analysis - No DARVO patterns detected - discussion focuses on systemic issues rather than individual blame ## 🎯 Conclusion Software maintenance remains stuck in 2015 because organizations treat it reactively rather than systematically. While AI has accelerated code creation, it hasn't improved maintenance capacity, creating dangerous gaps. The solution requires cultural change treating maintenance as a first-class citizen from day one, combined with systematic tracking and business-language communication. Success depends on leadership accountability at all levels and disciplined practices that prevent rather than fight fires. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Maintenance culture requires both blameless and accountable practices > [!quote] [Why software maintenance is stuck in 2015](https://youtu.be/gMn6JkLDaGc) by [[Lead Dev]] via [[YouTube]]. Published 2024. Accessed 2024-01-15. > "I believe in a blameless culture, but I also believe in an accountable culture." Essential framework for engineering leadership balancing psychological safety with responsibility. [view highlight](https://youtu.be/gMn6JkLDaGc?t=1125#H1) #culture #leadership ID:rw_001 ### [H2] AI creates dangerous capacity gaps in software maintenance > [!quote] [Why software maintenance is stuck in 2015](https://youtu.be/gMn6JkLDaGc) > "AI has changed the way we write code 10 times more than before but what hasn't changed is our capacity to maintain this code." Critical insight on AI's asymmetric impact on development velocity versus maintenance capability. [view highlight](https --- ## Full Transcript [00:12] Hi everybody. Uh a huge thank you today [00:15] for joining us for this discussion on [00:18] why software maintenance is stuck in [00:20] 2015. And this is a lead dev online [00:24] panel discussion created in partnership [00:25] with draft. The discussion today is [00:28] going to last approximately about 45 [00:30] minutes after which both myself and the [00:32] panelists are going to head over to the [00:34] lead dev Slack. Um we'll be answering [00:36] some of your questions there if you've [00:37] got them in the um panel Q&A channel. [00:42] And if you haven't already joined the [00:43] lead dev Slack, you can do so by going [00:46] to leaddev.com/join [00:49] slack. [00:51] We will also hopefully have time to [00:53] answer some of the questions either as [00:55] the panelists are going through and I [00:56] can work them in um or at the end. So if [00:59] you do have anything that you want to [01:01] ask us then feel free to submit them um [01:03] through the uh the Q&A feature on Zoom [01:06] um and I'll get to them like I say [01:08] whenever we can. Um but first we're [01:10] going to get started with just a few [01:12] basic introductions. My name is Sally [01:14] Le. Uh my pronouns are she and her and [01:17] I'm a fractional technology leader and [01:19] adviser based in the UK and I'm joined [01:21] by four incredible panelists today. I'm [01:24] really excited um that they're here with [01:26] us. They're going to be sharing their [01:27] experiences, sharing their insights and [01:30] I'm going to let them all introduce [01:31] themselves starting with AB. So Abby, [01:34] could you tell us a bit about you and a [01:36] bit about why you are particularly [01:38] excited about being here and this topic? [01:40] All right, no worries. Thanks Sally. Um [01:43] hi everyone. and I'm AB. I'm currently [01:45] the CTO and co-founder at [01:49] everyone calls us Metri Fox or Foxes, [01:51] whichever one you prefer. It's a [01:53] monetization platform for AI agents and [01:55] SAS companies. Before Metro, I worked as [01:58] a software engineer on multiple core [02:01] teams and a developer experience team as [02:03] well as an EM at places like Factorial [02:06] and Clue. having been on both sides of [02:08] the aisle, being someone who had to [02:10] maintain painful code bases as an IC and [02:13] also someone then being the person later [02:16] responsible for setting good standards [02:18] and trying to convince the business to [02:20] invest in them. I would say that I bring [02:22] a holistic view to the topic of software [02:26] maintenance and yes, I'm really excited [02:28] that we are discussing it. [02:30] >> Oh, thank you. I'm so glad that you're [02:31] here with us today. And next, I'm just [02:34] going to go over to Hila. So Hila, could [02:36] you tell us a bit again about yourself, [02:38] your background and why you're [02:39] particularly excited to be here today? [02:41] >> Sure. So I'm Hila Fish. I'm currently a [02:44] solutions architect in AWS and [02:46] beforehand I was a DevOps engineer. So [02:49] I'm looking at this uh particular topic [02:52] from both ends. So as a devops engineers [02:55] help as devops engineer helping uh [02:57] software developers enabled a an easier [03:01] software development life cycle as much [03:03] as I can and I seen a lot of um issues [03:07] uh there around CI/CD but also in how [03:10] they maintain their repositories [03:12] and in my current role I'm helping my [03:16] customers with overall AWS adoption but [03:19] my main focus was around AI as I think [03:23] That's most of what we all did uh the [03:26] past year. Uh so basically AI coding [03:28] assistants, chatbots and how we can help [03:31] our developers and our business succeed. [03:34] So I can bring some from my uh [03:37] experience and conclusions of that uh to [03:40] the table. [03:41] >> Fantastic. Thank you. And yes, we will [03:43] be talking about AI, not exclusively, [03:45] but it will be featuring today. But [03:47] before we get into all of that, uh [03:49] Reggie, so nice to have you here today. [03:51] Could you tell us a bit about you and [03:53] again you know what what your passions [03:55] are in this area why you're here today. [03:56] Thanks. [03:57] >> Absolutely. Absolutely. Hey everybody, [03:59] I'm Reggie Davis. I am a senior site [04:01] reliability uh engineer currently for a [04:04] start Australianbased startup uh named [04:06] Airlock Digital. I work with uh Elastic [04:09] and Home Depot and SlumberJ in the past [04:12] and uh I specialize in incident [04:14] management. Um, and so as a result, uh, [04:18] software maintenance is a is a thing for [04:20] me, um, because I typically see the [04:22] result or the outcome of the, uh, you [04:25] know, bad things getting introduced into [04:27] production environments. And so I have a [04:29] a a very much so strong passion uh, for [04:32] this topic. Uh, especially in the age of [04:34] AI, I think it's probably more important [04:36] than ever to discuss software [04:37] maintenance. And uh, I'm really looking [04:39] forward to the conversation we're going [04:40] to have today. [04:41] >> Fantastic. fire fire prevention not [04:44] firefighting is always the best way I [04:46] think or that's how I feel anyway and [04:49] finally tal uh so great to have you here [04:52] over to you [04:53] >> uh thank you so my name is T I'm a [04:55] co-founder and CTO and CEO of Draft and [04:58] Draft is an agentic platform for [05:00] software maintenance reduction and [05:02] elimination that's what we do uh I [05:05] founded this company because before [05:07] Draft I was the head of DevOps and [05:09] platform engineering at big panda and [05:11] spot IO uh and I saw firsthand you know [05:14] the how much time uh and how much of our [05:17] budget goes into keep the lights on uh [05:21] versus innovating and creating new [05:23] stuff. uh and most of my time and most [05:25] of my job was how can I enable the [05:29] developers and the rest of the teams to [05:32] better prioritize or better understand [05:35] the impact of software maintenance and [05:36] tech that on our uh production [05:39] environment and our ability to uh create [05:41] new value. Uh that's what makes me so [05:45] excited about this topic. it it's kind [05:48] of funny because it's the most boring [05:49] part of software development, but it's [05:52] also the most important part of it. Uh, [05:55] and the fact that it's still stuck in [05:57] 2015, uh, is something I'm I'm actively [06:00] trying to solve. So, that's why I'm [06:01] here. [06:02] >> Well, again, if you've got opinions, if [06:04] you're out there watching, you think [06:06] it's the most boring or maybe the most [06:07] interesting, please do share your [06:09] questions and thoughts with us. Um, I'm [06:12] really excited though to discuss this [06:14] topic, to to get into it. I know that [06:15] everybody's got some really fantastic [06:17] experiences, different opinions. Um, so [06:20] yeah, we are talking about why software [06:21] maintenance is stuck in 2015. Um, 2015 [06:24] was actually the year that the original [06:27] Apple Watch um, released. It's the year [06:29] that samesex marriage was legalized in [06:31] the US and Windows 10 was released as [06:34] well. So, a lot has changed in the world [06:36] since then, yet a lot also hasn't. Um so [06:41] today we're going to be covering some [06:43] really practical um experiences from our [06:46] panelists. We're going to be hearing [06:47] some fantastic tips and advice for you [06:49] to hopefully take back to all of your [06:51] teams. Um but first we wanted to sort of [06:54] sense check that everybody's on the same [06:56] page on the topic. So we're just going [06:59] to start by um talking through and [07:01] Reggie hopefully you can uh talk through [07:04] this with us about what we mean by [07:06] software uh software maintenance. Why [07:10] are we here talking about it? Why should [07:12] people care about it? I know that we've [07:13] heard a little bit in the intros. Um, [07:15] but yeah, let's let's get that [07:17] definition out there. What do we mean by [07:18] software maintenance? [07:21] >> Absolutely. I think typically like the [07:24] way I like to describe to my teams is I [07:26] like to look at software applications [07:28] like a home, right? It may take you [07:31] three months, four months, six months to [07:33] build a home, but you may be living in a [07:35] home for the next 30, 40, 50 years, [07:37] right? Are you going to build memories? [07:38] All of these things are going to happen [07:39] in this home. And a lot of people get so [07:41] caught up in the build that a lot of [07:43] people forget about the actual [07:44] maintenance and the overhead that comes [07:46] with the home. It's going to be light [07:47] bulbs that need to be changed. We got to [07:50] uh change out the air filters. We got to [07:52] mow the grass. We got to do all of these [07:54] things. And those little things over [07:56] time add up a lot. And so I think uh far [08:00] too often um our mental models have not [08:02] necessarily updated to kind of recognize [08:05] software as that. we just think we can [08:07] keep building and building and building [08:09] on to it, but if the home starts off as [08:11] a as a one-story home and then you add [08:13] two more stories, can't be surprised [08:15] when you have foundation issues in a [08:17] couple of years. And so I think as a [08:20] result, um I think a lot of times things [08:22] have moved so fast and we focus so much [08:25] on like let's let's introduce new [08:27] features, let's do all the nice cool [08:29] things that everybody's doing that a lot [08:31] of times we overlook the maintenance. [08:33] And so, uh, I think it's extremely [08:35] important, especially now that we're [08:36] moving as fast as we are with AI being [08:38] introduced into the mix. It's extremely [08:41] important to really talk about [08:43] maintenance and actually have uh [08:45] procedures and structures and standards [08:47] around it because at the end of the day, [08:50] your leaders or your CTO's or whoever, [08:52] nobody's going to go and say, "Well, I'm [08:54] blaming the AI." They're going to look [08:55] at you, you know, they're going to look [08:56] at the person that that merged that PR [08:58] in, that that brought that code in, all [09:00] of that kind of stuff. And so now more [09:02] than ever, I think operations and and [09:04] just the the maintenance overhead that [09:06] comes with building software, I think [09:08] it's is it's is more important than ever [09:10] to talk about these types of things. [09:13] >> I'm really trying hard not to make the [09:15] snarky comment at the moment about the [09:17] leaders blaming AI, which is kind of in [09:19] the news at the moment. Um but I will uh [09:22] resist from that. Um but yeah, [09:25] fantastic. Thank you. And I think that [09:27] um that that kind of investment and [09:29] knowing how to talk to your senior [09:31] leaders, knowing how to kind of sell the [09:33] value of that as well is super super [09:35] important. And I think that's something [09:37] that that we'll likely um touch on a [09:39] little bit. Um but I'm also really [09:42] hoping that we can um set the scene a [09:45] little bit. um Hila, I'll pass over to [09:46] you in a sec of and we've got this this [09:50] title of software maintenance being [09:52] stuck in 2015, but I'd love to hear a [09:54] little bit of more about um the aspects [09:56] of maintenance that you feel have [09:59] changed over the years. Where are those [10:01] trends? What what has differed? Um and [10:04] where are the bits that haven't? Those [10:05] are the bits that we we're sort of [10:07] obviously talking about a little bit [10:09] where everybody's getting stuck. Um but [10:11] what have you seen change and and what [10:12] have you felt has stayed the same since [10:14] around then? [10:16] >> So I would leave the the core parts to [10:19] people that actually did development [10:21] here. I will currently focus on the [10:23] peripheral which is still very very [10:25] important. For example security okay all [10:28] of the vulnerabilities that developers [10:30] don't like to deal with and they [10:33] introduce packages and in the [10:34] requirements they uh use a specific [10:37] package. But what if they there is a CVE [10:40] or what is there any vulnerability that [10:42] they need to address? It's the job of [10:44] the DevOps engineers to incorporate um [10:47] scanning tools in the CI/CD and if [10:49] something happens then we will tell the [10:51] developers and maybe they will fix it [10:53] maybe not and then that's a hideous part [10:56] to get to production in a state where we [10:58] are not sure what do we have false [11:00] positives yes no so all of the the topic [11:02] of security vulnerabilities is something [11:04] that I think got addressed very well um [11:09] in the in the upcoming years after 2015 [11:12] uh some tools better than others to to [11:16] address false positives to help [11:18] developers deal with it before getting [11:20] to production before not getting to a [11:22] place where it um blocks any deployments [11:27] to production for example. So all of the [11:29] this thing is very important and usually [11:32] developers don't like to to deal with [11:34] it. They just want to write code and [11:36] that's it. But security vulnerabilities [11:37] is something that is part of the the [11:39] day-to-day and nobody can really ignore [11:41] that. So I would say this is one thing [11:44] that I personally as a develops engineer [11:47] uh um dealt with it. Other aspects are [11:52] um whether developers understand or [11:56] would like to take that the fact that [11:58] software [11:59] maintenance is al is only the software [12:01] development only their code or also the [12:04] other parts like CI/CD some developers [12:06] say no no devops and should do it and [12:08] that's it and some developments say no [12:10] I'm building the image I'm building the [12:13] all the dependencies I should be the one [12:15] to handle also the deployment to dev and [12:18] and then production Yeah. So, this also [12:21] got addressed. Not quite as good as I [12:25] would have hoped because it's still a [12:26] matter of culture and perspective, but [12:30] it is at least something that was [12:32] addressed. And um yeah, so that's the [12:37] peripheral stuff that I got to [12:38] personally uh um tackle, but I will I [12:42] think we'll go to AB to to discuss the [12:45] hardcore parts of software maintenance. [12:48] maybe I'll jump in and add my take on [12:50] this one. So I I'll start by what has [12:53] changed. So I feel like even before the [12:56] AI uh revolution or the era that we are [12:59] seeing right now, the surface area [13:02] exploded. Okay, much more microservices, [13:05] dependencies, manage platform, the [13:08] release velocity was much higher even [13:11] before the AI if we compare it to 10 [13:14] years ago. So everything has changed [13:17] cloud SAS open source change [13:20] continuously and it's not something that [13:22] we're managing. So it's someone's else's [13:25] code running in our production systems [13:27] and all these moving parts and all these [13:29] interconnections is something that [13:31] someone needs to be in charge of. Um [13:35] what has changed also I guess our [13:39] expectations from different uh owners uh [13:44] the code owners or the the the devops of [13:46] platform engineering teams the rise of [13:48] IDPs all these things changed what [13:51] hasn't changed and this is the reason we [13:53] are here today is the fact that software [13:56] maintenance is still reactive and we are [13:58] only dealing with it when it's too late [14:00] or something is burning or there is like [14:04] a a huge shout from someone in the [14:07] organization saying we must deal with it [14:09] right now because something is about to [14:11] happen or already happened. It's still [14:14] ticket driven uh instead of I'll say [14:17] risk driven or part of the business [14:20] decisions. Um and [14:24] yeah and if I'm adding AI to everything [14:27] I'll say that AI has changed the way we [14:31] write code. So now we write code 10 [14:34] times more than before or even more. Uh [14:38] but what hasn't changed is our capacity [14:41] to maintain this code. So AI is not [14:43] working as well uh in maintaining on or [14:47] having the full context of what's going [14:49] on as it works when it's generating [14:53] generating new code. And that's one of [14:55] the biggest problem we need to solve [14:56] right now because uh the the gap between [15:01] the velocity or frequency of changes to [15:04] what we can actually maintain and uh you [15:07] know invest in keeping things running [15:10] that that's the big the biggest issue [15:12] that we have today. Um yeah I guess that [15:16] that's my take on this one. [15:19] Thank you. And I would love to go over [15:21] to to AB. Um AB, welcome again. I know [15:27] that you've experienced some some pain [15:29] points. Uh might have some great [15:30] examples to share with the audience [15:32] today. So could you talk us through um [15:34] maybe you know what the biggest pain [15:36] points you have experienced in the area [15:38] of kind of software maintenance are? [15:40] >> All right. Um, as it regards pain [15:42] points, I would say that two stand out [15:44] for me. And the first one is something [15:46] everybody whines about every time. Tech [15:49] debt. But the funny thing about tech [15:52] debt is we often define it as a [15:54] conscious decision to take a nonoptimal [15:58] path to achieve a goal in the short [16:00] term. However, majority of the tech that [16:03] you see, they weren't conscious [16:05] decisions. [16:07] They are just bad code and poor designs [16:10] that could have been written differently [16:12] from day one. And this causes like two [16:15] major problems. Let's start with the bad [16:18] code. First of all, that spreads in some [16:20] cases. New journals come in, they assume [16:23] it's the standard and then they [16:25] propagate it. Before you know, in a [16:28] situation where there's no culture of [16:30] keeping track of tech debt or areas that [16:32] need some rework, you just notice that [16:34] things start getting worse and [16:37] it's more difficult to maintain [16:40] something the more you postpone it. I [16:42] like the um the analogy that Reggie used [16:46] about a home. It's like when people are [16:48] building, they're focused more on the [16:50] building. They don't think about the [16:51] fact that this might be a bungalow now [16:54] but maybe we want to make it a duplex [16:56] later or this may be a one story now but [16:59] maybe want to make it two stories later. [17:01] It's just about what's the requirement [17:03] now and then they work with that and [17:06] then it becomes really hard to maintain [17:08] the code. The second thing is even when [17:11] tech debt is intentional [17:15] we never really get back to it. I have [17:18] seen to-dos that are 3 years old and I [17:21] had to personally ask like is there [17:23] anyone planning to actually do this [17:25] thing because this to-do thing here is [17:28] like 3 years old. So we never get back [17:31] to it and um many times because things [17:35] currently work and we have no push to [17:37] rework them or keep the system [17:39] maintained. We wait till there's a [17:42] breakage in the system or there's a huge [17:44] bottleneck and then that's when we [17:46] realize as Tal said we're more reactive [17:50] as opposed to proactive. [17:52] The second pain point would be something [17:54] that I would say Hila is very passionate [17:57] about and that's documentation. [18:00] Software is incredibly hard to maintain [18:03] when you do not have the slightest idea [18:05] why it was built the way it was. someone [18:08] could make a small change and you think [18:10] it's totally unrelated and you're like [18:12] maybe everyone says production is down [18:14] and you're like can't be me what I did [18:16] is totally unrelated and it was you [18:19] >> can I use reactions I want to use [18:21] reactions and put you some a lot of [18:22] confetti please [18:25] so on I mean oh my god [18:28] >> but that's because there's no like there [18:31] are no docs and the thing is people [18:33] think of docs as this huge page [18:36] documentation can ring anything from [18:39] comments in your code to say maybe don't [18:42] touch this part because it's related to [18:44] this other part or something that can [18:46] help people understand how things work. [18:48] They can be RFC's erds but in whatever [18:50] come they in in whatever form they come [18:53] in it's um they totally make software [18:57] maintenance easy and and this is an area [19:00] I've seen a lot of teams struggle in or [19:04] struggle with. Something I would say is [19:06] that these pain points become very [19:08] obvious when you find it difficult as a [19:11] team to adapt to changing requirements [19:14] and you'd see that when product comes in [19:17] and says oh we just need to make this [19:19] small change and engineering it's like [19:21] that must be easy and then you go touch [19:24] the code and you then realize that the [19:26] system was not built to be extended and [19:28] it hasn't been properly maintained and [19:30] suddenly a small change leads into a [19:32] bigger project but that's because we [19:35] didn't do the right thing in the first [19:36] place. So yeah, those are the two main [19:39] pain points I have experienced. [19:41] >> Fantastic. Thank you. Uh well, not [19:44] fantastic that you've experienced them, [19:45] but I think it is, you know, the [19:47] reaction you've got here in the in the [19:49] group I think is probably reflective of [19:51] how people are are feeling outside as [19:53] well. Um I would really love to hear [19:56] from Reggie on this because you've [19:57] talked about a lot of things there that [20:00] are kind of baked into the culture. So [20:02] standards juniors coming in feeling like [20:04] okay this is the standard that we we [20:06] need to align with. Um so Reggie how um [20:10] how would you describe the the key [20:13] cultural drivers that really contribute [20:16] to a successful culture uh of [20:19] maintenance software ownership all of [20:21] all of that good stuff. Um if we're [20:23] going to flip it around we've heard [20:25] about the pain points. What does a great [20:27] culture look like? What should people be [20:28] doing in a practical level um to turn [20:31] that culture around or to to get to a [20:33] place that they they aspire to? [20:35] >> Absolutely. I love this question. Um [20:37] it's funny. It we had an incident the [20:39] other day at work and um I had a [20:42] conversation with a manager and I told [20:44] him, you know, we're a startup. We, you [20:46] know, we're figuring things out and uh [20:48] one thing I was telling him I'm like, [20:49] you know, I believe in a blameless [20:51] culture, right? But I also believe [20:53] believe in a accountable culture, right? [20:56] I think a lot of times people just say, [20:59] "Oh, well, it's blameless." Like, we [21:00] don't blame people. But you have to take [21:01] accountability, especially from [21:03] leadership, right? Because to the point [21:05] that AB was making, those juniors, [21:07] those, it ain't necessarily got to be a [21:09] junior. It could be just a person that's [21:10] on board into the company. They're [21:12] coming in and they're looking at the [21:14] code base and they're going to follow [21:15] the patterns that are already laid in [21:16] front of them. And if and if and if [21:19] people aren't able to be able to go to [21:22] the people that have written the code [21:23] and do all of the things and talk about, [21:25] hey, why we make this decision or what [21:27] we doing here and all of that kind of [21:28] stuff, then what is going to happen is [21:30] it's like now this person is going to [21:31] create a brand new mental model of what [21:33] they should be doing and they're not [21:35] necessarily following the patterns, [21:37] right, that maybe leadership believes [21:39] that they should be following. Which [21:40] leads me into my other point, which is [21:42] the other part about making a great [21:44] culture is discipline. You have to have [21:46] discipline on a leadership level. And so [21:49] even if that means as a senior engineer, [21:51] I know I don't like writing [21:52] documentation and well that's not [21:54] necessarily me. I love writing [21:54] documentation. But even if I don't like [21:56] writing documentations or I don't like [21:58] doing ADRs or I don't like scoping out [22:00] my projects or whatever it is, you have [22:02] to do it because this is the road map. [22:05] This is the blueprint that everybody [22:06] else is going to follow. Not just over [22:08] the next three months, but really for [22:09] years to come. Because typically once [22:11] that code goes out as AB said like you [22:14] might intentionally introduce tech debt [22:16] into your environment but the reality is [22:18] is that you may not get back to it 6 [22:21] months a year you may never get back to [22:23] it. So at the very least it's important [22:25] to have strong discipline around areas [22:28] when it really when it comes to [22:29] communication communicating all of these [22:31] different ideas having diagrams having [22:34] docs leaving comments in the code [22:36] because you don't know the learning [22:38] style or the way that people are going [22:40] to be looking at the code and the [22:41] environment when they walk into your [22:43] when they walk into your environment. [22:44] And so it's important to have really [22:46] really strong discipline um when it [22:48] comes to these areas because if not then [22:50] people are going to go off like people [22:52] gonna go off and start building all [22:53] these mental models and then the [22:55] maintenance becomes even harder because [22:56] you got a team of seven or eight people [22:59] and you got four or five different [23:01] mental models around the business domain [23:03] and that's extremely difficult to manage [23:06] over a course of time. [23:10] >> Let me just say something there. Let me [23:12] just add something about the whole drive [23:15] for culture. I noticed that some people [23:18] do feel that if I report something that [23:20] means I'm the owner and so they refrain [23:24] from actually doing that you you [23:26] encounter tech debt. you find that this [23:30] isn't right but instead of saying oh [23:33] this isn't right we should change it [23:34] you're scared that if I say that then I [23:37] have unintentionally availed myself as [23:39] the owner or the person who has to [23:41] change this and so they actually do [23:44] nothing so I agree that we should have a [23:46] culture of logging things to say okay or [23:48] tracking tech there to say I found this [23:51] thing this is this is what I think it is [23:53] this is how I think we should evolve it [23:56] and just keep it there so we have that [23:57] visibility [23:58] And then we can begin to think about how [24:00] we want to tackle things [24:05] >> completely. [24:05] >> Absolutely. [24:07] >> Reggie, I just wanted to follow up on [24:08] your point um for my clarification, but [24:12] also it might be an interesting point as [24:14] well of you talked then about [24:15] accountability uh and leadership [24:18] accountability as well. My take is um [24:22] that I'm interpreting that to mean kind [24:24] of leadership uh of all levels. Is that [24:28] kind of what you mean? Do you mean that [24:30] there should be accountability [24:31] throughout the org or you [24:34] >> Yeah. [24:34] >> No, absolutely. It got to be throughout [24:36] the org because like when we talk about [24:38] culture, it's engineering culture. It's [24:40] not the culture of a team. Yeah. [24:42] Obviously, your team may have your own [24:43] culture, but at the end of the day, you [24:44] all work for a business and the business [24:47] has these objectives that they're trying [24:48] to drive towards. So it has to be the [24:50] culture around the engineering. I think [24:52] that's something that that can be very [24:53] difficult especially as you scale out a [24:55] lot and I know we had a lot of issue [24:57] like this when we were at when I was at [24:59] elastic because you know you got people [25:01] across different parts of the world and [25:03] they all have different mental models of [25:05] what's going on. So, it's extremely [25:07] important for leadership on every level [25:10] to really embody these ideas culturally [25:13] around the engineering culture that we [25:14] want to build because if not, you're [25:16] going to have people coming in being [25:17] like, "Oh, well, y'all y'all aren't [25:18] doing this. Well, we did this at my last [25:20] company." Then they're gonna come in and [25:21] try to do their own thing and all this [25:22] kind of stuff and they might not [25:24] necessarily be the culture that they're [25:25] trying to develop there. [25:28] >> Great. Thank you for clarifying. I just [25:30] wanted to I know that that's a whole [25:32] topic in itself kind of like what is [25:34] leadership? what level, you know, does [25:35] leadership kind of kick in as a an [25:37] attribute? Um, so yeah, I think that's a [25:40] super super important point when you're [25:41] trying to build out the culture. Um, but [25:44] kind of moving, not moving away from [25:46] people, um, but thinking less about [25:49] individuals and more about tooling. [25:52] Hila, I know that you've got some loads [25:55] of experience and some really great [25:56] opinions uh, around AI, particularly [25:59] when it comes to software maintenance. [26:00] So I'd like to ask how you see the [26:03] balance of maintenance responsibilities [26:06] playing out between humans and AI [26:08] particularly as more and more companies [26:10] more and more teams adopt um the the [26:13] tools that we're seeing is so common [26:14] place nowadays. [26:16] >> So the the term vibe coding emerged and [26:20] everybody got excited about it but it's [26:23] good for dev. It's good for prototypes. [26:25] It doesn't good it's not good for [26:26] production. So I think that once I hope [26:31] people will understand that it it's good [26:34] until a certain point that's it but we [26:36] can see now tools emerging understanding [26:39] that so basically taking AI and uh [26:43] having the built-in notion of not [26:48] vibe coding but how I call it or AWS [26:51] call it specdriven development to use AI [26:55] but in a very methodological I hate this [26:58] word methodologic [27:01] I think way of doing things of of [27:04] developing um a feature for example. So [27:08] again I didn't mean to do a shame [27:10] shameless plug but here it is very short [27:12] kirao our IDE it is it has built-in [27:16] specdriven development and why is it is [27:18] so important because it forces the the [27:20] developer to work in a certain way. So [27:22] once you say in a natural language I [27:25] want to build a feature or I want to add [27:27] a feature to my [27:29] product that does ABC then the ID [27:33] automatically says okay cool I'm going [27:34] to build a spec that introduce the [27:37] requirements you need to go over it see [27:39] if it makes sense if this is what you [27:41] meant has um aligning to the user [27:44] stories to see that this is something [27:46] that you actually want to do and [27:48] understand why then to the design and [27:50] then to the actual tasks And that way [27:52] because if you don't do that not all [27:55] developers will do it themselves like [27:57] okay let's work method you know in a in [27:59] a very organized way let's do it you [28:01] have to have a very built-in mechanism [28:04] to make developers do it and then once [28:07] you have it you AI is is fully at your [28:10] disposal you can do whatever you want [28:12] with it it it does everything it you can [28:15] al also leverage uh agents to do h to [28:19] handle a lot of the tech that in the [28:21] background while work on in the ID. So [28:23] this is awesome assuming that it [28:26] leverages this uh approach because that [28:29] way you can um take the full power of AI [28:32] but in a somewhat constraint way that [28:35] will help you create better and quality [28:38] and more quality uh u products and and [28:41] and features to your production [28:43] environment. So AI is great, but you [28:46] need to make sure it follows a certain [28:48] um methodology to make sure that you [28:51] actually create something that is [28:52] worthwhile to use. [28:56] >> Okay. I didn't know whether we'd have [28:58] any other people trying to jump in on [29:00] that one. [29:01] >> Yeah, I can. I have my opinion. So you [29:03] know I'm a bit biased of course building [29:06] a tool solving tech that and and [29:09] software maintenance friction but I I [29:11] will try to reframe [29:13] uh the work or or what we're trying to [29:16] do here and say that you know I [29:18] mentioned before that what has changed [29:21] the surface and now we have a lot of [29:24] open source tools and third party [29:26] vendors and managed services and cloud [29:28] providers and each one of them comes [29:31] with a life cycle or or a end of life [29:36] timeline. So if you're leveraging I [29:38] don't know RDS or Kubernetes or whatever [29:41] technology it is in any cloud provider [29:45] it comes with a clock and the moment you [29:48] started using it you need to plan ahead [29:51] the next upgrade and it's never a [29:53] vanilla upgrade. So you want to upgrade [29:55] your uh I don't know posgress or open [29:58] search or uh MongoDB database. So the [30:03] data the database team or the devops [30:05] team are in charge of the actual change [30:08] of the database but the development team [30:12] needs to understand the breaking changes [30:14] the change of behavior uh all the bug [30:17] bugs introduced or fixed in the next [30:19] version and all this work [30:22] they can't solve it because it's a black [30:24] box and a black box someone is managing [30:26] a technology not you are not the subject [30:29] owner expert and you also cannot not uh [30:32] folk this technology to fix something. [30:35] You are dependent on someone else to do [30:37] the job and you are dependent on [30:39] understanding how it affects you and [30:41] what you need to do in order to keep [30:43] your business running. So I guess what [30:46] is missing is first of all uh visibility [30:50] to the entire tech stack the different [30:53] layers of the tech stack because it's [30:54] not just infrastructure not just code [30:57] not just runtimes or operating system [30:59] it's it's a whole uh and the second [31:01] thing is a shared language so you [31:04] mentioned it before I think Reggie when [31:05] you spoke about leadership and the [31:08] organization needs to speak the same [31:10] language uh and in security they were [31:13] able to do it And you know everything is [31:15] about risk and you have critical and [31:17] high and medium and low and then you [31:20] it's easy to to you know get a CV score [31:23] it some way and then you have an SLA to [31:25] deal with it. That's something that [31:27] security teams did very well uh in order [31:31] to react to something that is not under [31:33] their control. Um we need to find the [31:36] same language uh and to find a way to [31:39] make maintenance and routine maintenance [31:42] and uh something boring again not [31:45] something that all all the organization [31:47] like all ends on deck because it's about [31:50] to break production how we can be [31:52] predictive and be proactive and take all [31:55] the friction and maintenance toil that I [31:57] just mentioned you know someone is [31:59] getting this message saying uh this [32:01] database needs to be updated by this [32:04] eight, but then you start the meetings, [32:06] right? You have a meeting with the [32:08] leadership and you say, "Hey, we don't [32:10] know how it affects us. Let's schedule [32:12] some time in the next sprint to do some [32:13] research pre, you know, two weeks later, [32:16] the next sprint. Okay, now we need to [32:19] prioritize it. Is it important enough? [32:21] Not different teams need different [32:23] changes. For some, it will be uh you [32:26] know a a green green field just upgrade, [32:29] nothing will break. For others, it's a [32:31] refactor of the entire codebase." So all [32:34] these main you know I'll say manual [32:38] frustrating work that no one comes to [32:40] job and say hey I'm excited about [32:42] researching how MongoDB broke my [32:45] production today. No one does this. So [32:48] it it's something that we need to find [32:49] the right tools and or the right uh [32:53] methodologies to solve. Um so so that's [32:57] the biggest opportunity I feel uh we can [33:00] introduce right now to this area. and of [33:02] course leveraging AI to do most of of [33:05] the parts. [33:06] >> I think I've actually been really lucky [33:08] in that I've worked with a lot of [33:10] engineers I think relatively speaking [33:12] who really enjoy that kind of work and [33:15] who are super proactive and take great [33:16] ownership. So I know I'm probably the [33:19] exception. Um but yeah that's that's I [33:22] think a really really great way to look [33:23] at it. Um so um yeah thank you for [33:27] sharing that. Um, are there any other [33:30] opportunities tal that uh that you [33:32] haven't covered? Because I know that we [33:34] were thinking about AI, but are there [33:35] any other kind of really really great [33:37] opportunities that people should be open [33:39] to thinking about or do you do you feel [33:40] like you you touched on everything [33:42] there? No, I feel like people should [33:45] start talking about a system of record [33:48] of software maintenance, a way to manage [33:50] it as a first class citizen and not just [33:53] something that uh you know it's reactive [33:55] and we deal with it when we have a fire [33:58] that we need to firefight. Um and we [34:00] also need a system of record uh to find [34:03] a way to reduce the manual work and [34:07] repetitive repetitive work that we are [34:09] doing in this areas. So I guess I kind [34:11] of talked about it before but but we [34:15] need to structure it in a way and you [34:18] see that Gartner is trying to come with [34:19] some methodologies to how uh you know to [34:23] to prioritize and and fit different [34:27] initiatives into boxes. Uh and we see a [34:30] lot of conversation in this area. It's [34:32] really one of the emerging trends uh now [34:35] with AI of course uh because it just [34:37] amplifies the problem and people meet it [34:41] in production much uh more more often. [34:45] Uh but yeah, this is the one thing that [34:48] I I will do tomorrow morning if I don't [34:51] have a systematic approach right now [34:53] that that's the one thing I'll do [34:55] tomorrow. [34:56] >> Thank you. Thank you. Uh just a quick [34:59] reminder to people watching if you want [35:02] to ask any questions to the panelists. [35:04] We may have a little tiny bit of time. [35:06] Um we'll see. Thank you to the person [35:08] who's literally just sent one in. So we [35:10] may not have as much time now. Um but if [35:12] you do want to send in any questions [35:14] then we'll either try and answer them [35:15] live um on the call itself or we will [35:18] jump over to the Slack channel um on the [35:21] lead dev Slack to answer those [35:22] afterwards. Um but we'll sort of we'll [35:25] move towards the the tail end of this. [35:27] So AB, I would really love to get your [35:30] thoughts. So um we've heard a little bit [35:32] from TAL in terms of opportunities and [35:34] recommendations, but do you have any [35:36] advice to people who are looking to [35:38] improve their software maintenance right [35:41] now? So what practically should they be [35:44] taking back to their teams after [35:45] watching here today? That's a very [35:48] interesting one. I would say that it's a [35:52] it's kind of a combination of what [35:54] everyone has said. First of all, culture [35:55] is important. It's important to begin to [35:59] build a culture where people don't see [36:01] maintenance as an afterthought or [36:04] something that we do after we ship. No, [36:06] you need to begin to think about it as [36:08] from the first line of code the [36:10] maintenance begins. So, we need to start [36:12] to ship what's maintainable and what's [36:15] extendable. The second thing is [36:17] something I feel a lot of people [36:18] struggle with and that's automation. [36:22] AI is here to stay whether we like it or [36:24] not. We're in the AI era. So, um we you [36:29] should try to automate as much as [36:31] possible. However, we have tools that [36:35] are built for this. So, as much as you [36:37] can automate um tasks that are boring, [36:43] but we know that should actually happen, [36:45] let's try to use tools that are built [36:47] for that to do those. And the next thing [36:49] will be understanding the business and [36:52] the environment. Some people make a case [36:55] for maintenance to their um maybe senior [36:59] their um senior leadership and they say [37:03] um things are not moving fast enough [37:05] because we're not doing the right things [37:07] but then they actually comfortable with [37:09] the speed. So that's not a good case for [37:12] the business. So you need to understand [37:14] the business so that you can make a good [37:16] case for it I would say. [37:20] Well, that actually leads really nicely [37:22] into one of the the questions that's [37:24] been asked in the Q&A feature. Um, and [37:27] I'll just uh read that out quickly, [37:29] which is what are ways that engineering [37:32] leaders can quickly pitch proactive [37:34] maintenance activities to product [37:36] owners, business owners, and other [37:39] non-technical stakeholders in their [37:40] organization. Put another way, how can [37:43] we avoid the project management overhead [37:46] of maintenance killing proactive [37:48] maintenance drive from engineers? Uh, [37:50] and I'll actually just paste that in the [37:52] chat so that our panelists can read and [37:54] absorb that if they uh can't see it. [37:56] Anybody wants to share any opinions on [37:59] that one? [38:00] >> Yeah, I I can I'll share what I did, you [38:03] know, in previous companies. uh I just [38:06] tried to create a shared language you [38:09] know when when things actually got [38:13] prioritized when there was a deadline [38:15] right when you say it's not something we [38:18] should do we can't not do it by this [38:21] date because this will be the business [38:23] impact um but you don't want to use this [38:26] pure mechanism all the time right so you [38:29] need to find a better way to frame [38:31] what's important to the business and [38:33] then say Hey uh first of all [38:38] I I'll stop for a second and say some [38:39] organization if you ask them they will [38:41] say that they have a bucket of 20 40 60% [38:45] of their uh quarterly uh I'll say bucket [38:50] to software maintenance and keep the [38:52] lights on. So that that's a a common [38:55] practice and it happens because they [38:57] don't know what will happen but they had [38:59] enough issues before to to understand [39:02] that something will pop up. So being [39:05] proactive is not just saying uh we will [39:08] keep this time aside for the next outage [39:11] to come or the next problem to come is [39:13] to be more uh proactive about it and say [39:17] hey this is the things that we already [39:19] identified for the next 6 months or 9 [39:21] months that we must deal with. Um here's [39:24] why we believe we must deal with it. [39:27] This is the business impact. This is how [39:28] it affects our ability to deliver new [39:31] features. Here's how it prevents us. Uh, [39:35] you know, here's the SLA breach. Here is [39:38] the uh I don't know the the the vendor [39:43] sunsetting something. All this [39:45] information if you get it in advance, it [39:48] kind of solves the discussion of uh to [39:52] try and convince people and do all these [39:55] roundts around uh the project management [39:58] side of things. So, so we all now speak [40:01] the same language and we understand why [40:03] it's important, why should I care and [40:06] why it sits under my roles and [40:08] responsibilities or under my ownership [40:11] and you can go ahead from pitching to [40:15] actually reasoning uh in a much higher [40:20] uh layer. So most of the time what I did [40:22] before I had this kind of mechanism I [40:25] tried to tie up uh my initiatives or the [40:28] things that I wanted to uh achieve in [40:31] this quarter or the next quarter with [40:33] the company OKRs. So a and it's kind of [40:36] what I'm doing right now as a CEO uh you [40:39] know selling to companies I'm trying to [40:41] understand what are the top priorities [40:43] they have whether it's leveraging AI to [40:47] you know release engineering capacity or [40:50] preventing outages or just reduce the [40:53] the manual work they're doing and then I [40:55] I try and translate what draft is doing [40:58] to the same uh objectives. So if you'll [41:02] be able to speak the same language the [41:04] business talks, that's the major step [41:06] you'll take forward in in changing the [41:09] way the culture of the organization [41:11] work. I hope I was able to answer this [41:13] one. [41:14] >> I want to add something to that really [41:15] quickly and that's because the question [41:18] says how can we quickly pitch right? So [41:21] it's like how can I just quickly put [41:23] that in there? And two things I would [41:26] say uh I always ask how fast do you want [41:29] to move and how effective do you want [41:31] your software to be? That's the fastest [41:33] way to just pitch it. So how fast do you [41:35] intend to move? Oh, we would like to um [41:38] ship seven features in seven weeks. [41:40] Okay, if you want to do that then these [41:42] are the things we have to do proactively [41:44] to enable the team to do that. How [41:46] effective do you want software to be? [41:48] Oh, I want um a lower latency. I want [41:51] this or that. So it's like as he said, [41:53] tie it to the business outcomes and [41:56] objectives and every business loves to [41:58] move fast. Every business wants to make [42:00] money. So yeah, if you can frame it that [42:02] way, that's a way to quickly pitch it. [42:06] >> Fantastic. [42:06] >> Not only that, it's just the fact that [42:08] if you find the reasoning for that [42:10] proactive work, how it will affect them, [42:13] then that's it. You're done. [42:16] >> Yeah. I I think and I just just to [42:18] piggyback on that like one thing that I [42:20] I find um we kind of sometimes as [42:24] engineers we fall short on is like we [42:26] always have our engineering hat on but [42:28] we don't never put our business hat on, [42:30] right? Or we don't put our finance hat [42:31] on. And a lot of times when we got to go [42:33] and talk to executives, they're not just [42:35] thinking about the X's and O's, right? [42:37] They're talking about the dollar signs, [42:39] the commas, and the decimals. And so as [42:41] a result, like I think that's a muscle [42:43] that does have to be worked. Like we got [42:45] to get out of the mindset of like oh [42:46] okay like we going to ship code in a [42:48] week two weeks. No like put your [42:50] business mind on. You know what I'm [42:51] saying? Put your business hat on and [42:52] think from the f from the reference of [42:54] the business because it becomes a lot [42:55] easier to communicate to your leaders [42:57] when you're speaking their language. You [42:59] can't expect them to come into your [43:00] world. You kind of got to step into [43:01] theirs. [43:05] >> So unfortunately we've only got a couple [43:08] of minutes left. Um, we do have some um [43:11] some questions that have come in um with [43:13] the um with the Q&A feature. Um Reggie, [43:17] thank you also for tapping away in the [43:19] background and kind of asking answering [43:21] some of those async. So, appreciate your [43:23] work there. Um I just did want to kind [43:25] of draw us to a close for the the live [43:27] stream though. Uh it's been a great [43:29] discussion. I've really enjoyed hearing [43:31] from all of you. I hope that everybody [43:33] watching has really enjoyed it too. And [43:35] some of the notes that I've been [43:36] scribbling down are just about the the [43:38] importance of culture. Um from AB you I [43:42] believe said uh maintenance starts from [43:44] the first line of code and we talked a [43:47] bit about how the balance between kind [43:49] of proactive and reactive maintenance is [43:51] very different and can lead to to very [43:52] different outcomes. Thinking about the [43:54] automation, thinking about um automating [43:57] the boring tasks, using appropriate [43:59] tools of which there are a lot out [44:01] there. Um, and also I love the the [44:04] analogy of the house. Um, I'm I often [44:06] think about it in terms of like [44:07] gardening, but I love that point about [44:10] it's a bungalow now, but where might it [44:12] go into the future? What's the [44:13] potential? Um, I I also write down the [44:17] fact that everything comes with a clock. [44:19] Um, and that we we need to put our [44:21] business hat on as well. Um, something [44:23] that I am similarly guilty sometimes of [44:26] not doing enough. Um, so I just wanted [44:28] to thank all of you again for all of the [44:30] amazing insights. Just to uh reiterate [44:33] in terms of anybody who hasn't had a [44:34] question answered yet, we're going to go [44:36] over to the lead dev slack um in the [44:39] panel Q&A channel hyphenated. So if you [44:43] want to come and continue the [44:45] discussion, we're all going to head over [44:46] there now. And if you're not signed up [44:48] already, you can get there by going to [44:49] leaddev.com [44:51] hyphen u leadv.com/joinhyenlack. [44:56] So, thank you so much again for joining [44:58] us today and we hope to see you again [45:00] next time. Bye. [45:03] >> Bye. ## Highlights - 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. ([View Highlight](https://read.readwise.io/read/01kgg2hhvrzc53rzdcx2xjpb0z)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hhwa4eec7mpkrkbfx4ck)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hhwpgga5gnxredctwf7y)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hhxq1b3y2zj0jz418815)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hhyxtfyhrctsg6c913sy)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hhzv2wprv0ywe3szcg6p)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hj24svmmrnrsan0vcsds)) - Tags: 👻 ai highlighted ## New Highlights added 2026-02-28 at 7:49 PM - 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. ([View Highlight](https://read.readwise.io/read/01kgg2hhvrzc53rzdcx2xjpb0z)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hhwa4eec7mpkrkbfx4ck)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hhwpgga5gnxredctwf7y)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hhxq1b3y2zj0jz418815)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hhyxtfyhrctsg6c913sy)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hhzv2wprv0ywe3szcg6p)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kgg2hj24svmmrnrsan0vcsds)) - Tags: 👻 ai highlighted