Too Much Maintenance and Too Little Real Engineering

“As an evolving program is continually changed, its complexity… increases unless work is done to maintain or reduce it.” — Meir M. Lehman, computer scientist and pioneer of the Laws of Software Evolution

Engineers can spend large portions of their time fixing legacy systems, addressing defects, updating documentation, and dealing with technical debt instead of designing and building something new.

When engineers complain about “too much maintenance and too little real engineering,” the underlying issue is usually not maintenance itself.

It is repetitive, reactive work that consumes capacity that should be spent producing permanent improvements, innovation, and better designs—what Google’s Site Reliability Engineering literature calls excessive “toil.” Google SRE

Consider three methods below for reducing maintenance and increasing engineering.

Measure and Reduce the Maintenance Burden

Engineers should first measure how much time is spent on maintenance, troubleshooting, rework, interruptions, and repetitive operational tasks.

Without data, “too much maintenance” remains a frustration rather than a problem management can quantify and address. Google SRE

Track recurring maintenance activities and rank them by frequency, engineer-hours consumed, and business impact.

Focus improvement efforts on the few activities that consume the most engineering capacity.

Identify work that is manual, repetitive, predictable, and capable of being automated—the characteristics Google associates with engineering “toil.”

Eliminating these activities gradually releases engineers for design, experimentation, development, and other higher-value work. Google Research

One way to reduce maintenance and increase engineering is to measure and reduce the maintenance burden.

Another is to engineer maintenance out of the system.

Engineer Maintenance Out of the System

Instead of repeatedly fixing the same problem, engineers should ask, “What engineering change would prevent this from happening again?”

Root-cause analysis can turn recurring maintenance problems into opportunities for redesign, simplification, automation, and improved reliability. Google SRE

Automate repetitive testing, deployment, monitoring, configuration, diagnostics, reporting, and recovery wherever the investment is justified.

DevOps Research and Assessment (DORA) research identifies practices such as automated testing and deployment as important capabilities for improving software delivery while reducing rework and unplanned work. Dora

Technical debt should also be identified and deliberately reduced rather than indefinitely tolerated.

Carnegie Mellon’s Software Engineering Institute notes that unmanaged technical debt can make systems progressively harder to evolve, modify, repair, and sustain. SEI

Two ways to reduce maintenance and increase engineering are to measure and reduce the maintenance burden and engineer maintenance out of the system.

A third way is to protect time for real engineering.

Protect Time for Real Engineering

Organizations should set an explicit limit on how much engineering capacity maintenance can consume.

Google, for example, caps operational work at 50%, reserving at least half its time for engineering projects, though the right percentage will differ across organizations. Google SRE

Managers can set aside protected engineering blocks devoted to eliminating recurring problems, improving designs, developing tools, and addressing technical debt.

Otherwise, urgent maintenance tends to continually preempt important long-term engineering work. Google SRE

The objective should not be zero maintenance, which is unrealistic, but continually decreasing the maintenance required per unit of engineering output.

The virtuous cycle is simple: less repetitive maintenance → more engineering time → better systems → still less maintenance. Google SRE

Three ways to reduce maintenance time and increase engineering time are to (1) measure and reduce the maintenance burden, (2) engineer maintenance out of the system, and (3) protect time for real engineering.

Engineers can spend large portions of their time fixing legacy systems, addressing defects, updating documentation, and dealing with technical debt instead of designing and building something new.

Don’t be one of these engineers.

Call to Action

• Eliminate manual, repetitive, predictable, automatable work to free yourself up for design, experimentation, development, and other higher-value work.

• Perform root-cause analysis to turn recurring maintenance problems into opportunities for redesign, simplification, automation, and improved reliability.

• Reserve at least half your time for engineering projects

“Every minute spent on not-quite-right code counts as interest on that debt.” — Ward Cunningham, computer programmer and creator of the first wiki, describing his debt metaphor in The WyCash Portfolio Management System, OOPSLA, 1992. This captures how yesterday’s shortcuts become today’s maintenance workload.

References

• Challoner, David, et al. “Eliminating Toil.” The Site Reliability Workbook, Google/O’Reilly Media, 2018. Provides methods for identifying, measuring, prioritizing, and eliminating repetitive operational work and recommends treating toil reduction as an engineering project. Google Research Google SRE — Eliminating Toil

• Rau, Vivek. “Eliminating Toil.” Site Reliability Engineering: How Google Runs Production Systems, Google/O’Reilly Media, 2016. Defines engineering toil and explains Google’s objective of limiting operational work so engineers retain substantial time for long-term engineering projects. Google SRE Google SRE — What Is Toil?

• Google. “Introduction.” Site Reliability Engineering: How Google Runs Production Systems, 2016. Describes Google’s 50% cap on operational work and its rationale for preserving engineering capacity to make systems more stable and operable. Google SRE — Introduction

• DORA. “Continuous Delivery.” Summarizes research connecting continuous-delivery practices—including automated testing and deployment—with improved delivery performance, quality, reduced rework and lower deployment pain. Dora DORA — Continuous Delivery

• Carnegie Mellon University Software Engineering Institute. “Managing Technical Debt with Data-Driven Analysis.” Describes technical debt as a tradeoff between short-term delivery and the long-term ability to evolve, modify, repair, and sustain systems, and emphasizes actively identifying and managing that debt. SEI — Managing Technical Debt

  
  ___________________________________
  
  
  

  Being a confident, engaging, and effective STEM speaker is a vital personal and professional asset. With more than 40 years of engineering experience and more than 30 years of award-winning public speaking experience, I can help you reduce your presentation preparatory time by 50%, overcome your fear of public speaking and be completely at ease, deliver your presentations effectively, develop your personal presence with your audience; and apply an innovative way to handle audience questions deftly.

  Working closely with you, I provide a customized protocol employing the critical skills and tools you need to create, practice, and deliver excellent STEM speeches and presentations. Let’s connect and explore how I can help you become the exceptional speaker you were meant to be. Please reach out to me at fr***@*****************ed.com or 703-509-4424 for a complimentary consultation. Schedule a meeting with me at calendly.com/frankdibartolomeospeaks

  .

  ©2026 DiBartolomeo Consulting International (DCI), LLC. All Rights Reserved. May not be used without permission.