
Episode #58
58. 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 in this podcast to reduce maintenance and increase engineering. 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 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 SEI — Managing Technical Debt ___________________________________ Being a confident, engaging, and effective technical 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 technical 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 frank@speakleadandsucceed.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.

