There is no software maintenance
I have had a really frustrating relationship with software maintenance in all of the companies I&#x27;ve worked for.<p>I&#x27;ve always been a strong, strong believer in an analogy like: How much time would you estimate that nuclear engineers spend operating and maintaining existing reactors, versus building new ones? How about public highway departments and building new roads, versus fixing or improving existing ones?<p>No analogy is ever perfect, but the only logical conclusion I can reach is that software engineering is a really weird discipline relative to practically all of its &quot;we build things that last years&quot; peers. Its weird because, well, our organizations in my experience chronically under-invest in maintenance then act flustered when new developments don&#x27;t meet deadlines or take forever; but its also weird because all of my experience screams at me &quot;I&#x27;m not even sure if we <i>know</i> how to maintain systems well&quot;.<p>I&#x27;ve seen this in one org (a public company you&#x27;d recognize); where years ago we had and met lofty goals like &quot;99.999% availability&quot;; today its a good month if we hit three-nines, API wide. In team meetings with really senior, smart engineers when we ask How Can We Improve This, you start observing this learned helplessness where they suggest small changes like, you know, adding a cache for some external API, or replacing the built-in HTTP client with some other one that has a more comprehensive knob for timeouts, or whatever. I talk with them privately and say: Is this really the best we can do? It isn&#x27;t; everyone knows that; but we will <i>literally</i> never have the product dev time to really fix the problem; maybe, taking what we&#x27;ve learned from some old system and building a new one, cut out layers of abstraction, reduce and simplify. So instead, we supplement the problem with complexity; and the thing we <i>won&#x27;t</i> admit is that this is like putting a bandaid on a skin tumor; it may improve the metrics on the short-term, but ultimately it <i>is</i> more complexity, it <i>is</i> more code, and in a lot of cases we&#x27;ve replaced one way that something fails, predictably, with N ways it can now fail, unpredictably, hopefully less often.<p>The other thing that no one will admit is: If the state-of-art way to fix something that needs fixed is to &quot;take what we&#x27;ve learned from the old thing and rebuild it&quot; (oftentimes, this is the best way; but that&#x27;s another discussion): No one lives forever, and No one stays at a company forever. Knowledge is Temporary. Through leaking knowledge or increasing scope, taking on maintenance today is <i>almost always</i> easier than taking it on tomorrow; and it usually leads to productivity boons which magnify over time.<p>I word a lot of that from the perspective of developer experience&#x2F;productivity, but it fits just as well with Security maintenance. I&#x27;m working alongside a company impacted by the recent LastPass breach. They were storing hundreds of internally minted JWTs in there like API keys; no expiration, and no way to revoke. &quot;We have to rotate these&quot;; well, lets take a look at this Jira ticket from four years ago where one of your senior engineers who left three years ago said we need to make these things expire, or at least add some kind of revocation list (ok, never word it like <i>that</i> to people; but that&#x27;s what we&#x27;re all thinking). We don&#x27;t have that; we can build it, but now the app has 5000x the traffic and complexity, so it&#x27;ll take time.<p>I share this talk by Johnathan Blow [1] all the time, because its fantastic and in this case he hits on a really good point: We only know how to do things by doing them. If we, as an organization, invest 10% of our time doing everything we can to keep existing systems running and productive; that may not be enough time to even develop the skills to <i>know</i> how to keep them running well and highly productive <i>if</i> we could fight for more time. One of the phrases I hear all the time, across many orgs: &quot;small steps toward improvement&quot;. I think people who say that have either given up (learned helplessness), and&#x2F;or they&#x27;re critically unobservant of the inherent entropy of software systems. There is, no doubt in my mind, a &quot;rate of decay&quot; of every software system; its different for all of them, its influenced by factors like product velocity, external integrations, language, etc; but they all have it. And if you aren&#x27;t investing <i>more</i> time in maintenance than your system&#x27;s rate of decay, you&#x27;re going to cause your People, your Customers, and if you&#x27;re very unlucky (cough LastPass) your Business a lot of pain.<p>But; my special variety of learned helplessness is that I think the people in charge of most orgs actually like pain, and like inflicting it on others. Most likely something to do with the observation that psychopaths and sociopaths tend to rise through the ranks a businesses faster than those with empathy.<p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ZSRHeXYDLko">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ZSRHeXYDLko</a>