Chapter 15 — end of Part II — of Software Engineering at Google Book Summary

Mastering the Art of Software Deprecation

Dive into Google’s approach to software deprecation. Learn the whys and hows from Chapter 15 of Software Engineering at Google.

Reader guide of series

About the Book

Have you ever wondered what powers the technological giant that is Google? The key lies in their approach to software engineering, a subject masterfully dissected in the book “Software Engineering at Google” by the acclaimed Titus Winters and meticulously edited by Tom Manshreck.

In a rapidly evolving technological landscape, equipping yourself with the foundational principles of contemporary software development isn’t just beneficial; it’s essential. This book promises a wealth of knowledge to aid your personal and professional growth.

Why Read This Summary Series

As you tackle this learning journey, my series of detailed chapter summaries will be your guiding hand, helping you:

• Understand Google’s gold standard principles with ease.
• Engage in thoughtful discussions fostered through deep insights.
• Save time by getting to the heart of each chapter quickly.

Don’t just take my word for it; dive in and experience the rich reservoir of knowledge yourself. Find the complete summary series here:

• Note: This is the final chapter of part II of the book and the final chapter that I am summarizing.

What to Expect in Each Summary article

Every article is based on a chapter of the book and offers:

• A TL;DR section for a quick snapshot of key insights.
• An in-depth analysis of the chapter’s core concepts.
• Conclusion to summarize the learnings.

The goal is to present you with an unbiased view as I focus on condensing the book’s key insights without injecting personal opinions.

Are you ready to journey into the depth of Google’s software engineering brilliance? follow me, subscribe to the newsletter, or contribute by buying me a book to support this series and fuel this voyage of discovery.

TL;DR

Chapter 15 of “Software Engineering at Google” explores the intricacies of software deprecation, delving into its importance, challenges, and strategies. Deprecation is the process of systematically phasing out outdated software systems, reducing maintenance costs and improving efficiency. It’s rooted in the understanding that code can become a liability over time, and deprecation helps remove excess code and systems. However, it’s a complex task due to unexpected user dependencies, emotional attachments, and the fast-paced technological environment. Effective deprecation requires proactive design considerations, differentiating between advisory and compulsory deprecation, and implementing clear warnings. Successful deprecation also relies on dedicated ownership, setting milestones, and using appropriate tooling.

Introduction

In Chapter 15, “Deprecation,” and the last chapter I am summarizing, Douglas Adams humorously introduces the concept of software deprecation, a key aspect of software engineering. The chapter explains that deprecation is the process of systematically phasing out obsolete systems, which, despite not degrading physically, become outdated due to technological advancements. Effective deprecation, ideally considered at the design stage, is crucial as it reduces maintenance costs and increases efficiency by removing redundant, complex elements. However, the process is challenging and unpredictable, as illustrated by Google’s experiences with its internal systems. The chapter focuses on the technical and policy aspects of deprecating software systems, distinguishing it from end-user product deprecation. Overall, it highlights the complexities and evolving nature of removing outdated systems in the technology industry.

Why Deprecate?

In the world of software engineering, the concept of deprecation is rooted in the understanding that code is more of a liability than an asset. This might seem counterintuitive, especially when we often think of code as the backbone of digital solutions. However, the true cost of code becomes apparent not just in its creation but more so in its maintenance over time. The operational resources needed to keep a system running and the efforts to update it as surrounding ecosystems evolve can be substantial. These factors make it essential to evaluate whether it’s more beneficial to maintain an aging system or to phase it out.

Deprecation isn’t about dismissing a system solely because of its age. Age doesn’t inherently make a system obsolete. There are systems, like the LaTeX typesetting system, that have been refined over decades and remain relevant. Deprecation is more about recognizing when a system has become demonstrably outdated and when there’s a better alternative available. This alternative might be more resource-efficient, secure, sustainable, or simply bug-free. The existence of two systems serving the same purpose might not seem problematic initially, but over time, the maintenance costs and complexities can escalate. This duplication can hinder the evolution of the newer system, as it often has to maintain compatibility with the old one. Removing the older system can allow the newer one to develop more freely and rapidly.

It’s worth pondering why, if code is a liability, so much effort is put into building software systems that last for decades. The key lies in understanding that the value isn’t in the code itself but in the functionality it provides. Functionality that meets user needs is an asset, and the code is just a means to achieve it. The goal should be to deliver maximum functionality with the least amount of code, thereby reducing the associated liabilities. Rather than focusing on the quantity of code, the emphasis should be on its efficiency and the functionality it delivers per unit of code. Deprecation plays a critical role in this process by allowing the removal of excess code and systems that are no longer necessary.

However, deprecation must be approached judiciously. Just like a city can’t pave all its roads at once without causing disruption, software organizations need to balance their deprecation efforts. It’s essential to select deprecation projects carefully and commit to completing them, ensuring that the process is manageable for both the teams involved and the end-users. By strategically phasing out outdated systems and code, software engineering can continue to evolve and adapt, delivering greater value with less liability.

Why Is Deprecation So Hard?

Deprecation, the process of phasing out obsolete software systems, is a complex and challenging task in software engineering. This complexity stems from Hyrum’s Law, which states that the more users a system has, the more likely it is that they use it in unexpected ways. This makes deprecating and removing such a system a significant challenge, as users might have grown dependent on it in ways that weren’t initially anticipated. Deprecation is not just about altering a system; it’s about completely removing its behaviour, which can disrupt numerous unforeseen dependencies.

One of the main reasons deprecation is hard is that it’s often not feasible until a newer system offering similar or improved functionality is available. However, even when a new system is in place, it’s rarely a perfect match for the old one, necessitating careful evaluation of each use case in the context of the new system. An additional challenge arises from the emotional attachment developers have to the systems they’ve helped create. At Google, for instance, developers have expressed resistance to removing old code they’re fond of despite its obsolescence.

Another aspect that makes deprecation challenging is the nature of the technological environment, which is often complex and fast-paced. At Google, there’s a joke that there are two ways of doing things: the deprecated way and the not-yet-ready way. This reflects the reality that new solutions are often just on the brink of completion. Navigating this environment requires good documentation, expert guidance, and clear communication.

Funding and executing deprecation efforts can also be politically and financially challenging. The costs of maintaining an obsolete system are not always apparent, making it difficult to convince stakeholders of the necessity of deprecation efforts. On the other hand, incremental deprecation, which involves gradual refactoring and improvement of existing systems, can be a more manageable approach. This method allows for the continued operation of the system while facilitating gradual improvements and value delivery to users.

Deprecation During Design: A Proactive Approach

Interestingly, deprecation should be considered right from the design phase of a software system, akin to practices in other engineering disciplines. For example, the design of a nuclear power plant includes plans for its eventual decommissioning. Unfortunately, software systems are often not designed with deprecation in mind, partly due to a corporate culture that emphasizes quick development and launch of new products. Planning for a system’s eventual obsolescence is not only a practical necessity but also a psychological challenge for engineers who are invested in building and launching new systems.

When designing systems, engineers should consider how easy it will be for users to migrate to a potential replacement and how parts of the system can be replaced incrementally. Managing dependencies effectively is crucial in this process. The decision to support a project long-term is made at the beginning of its lifecycle, and once a system exists, the options are to support it, deprecate it carefully, or let it fail due to external events. These choices vary based on organizational needs and priorities.

Types of Deprecation in Software Engineering

Deprecation in software engineering isn’t a one-size-fits-all process but a spectrum of approaches, ranging from gentle nudges to mandatory actions. This range can be broadly divided into two categories: advisory and compulsory deprecation.

Advisory Deprecation

Advisory deprecations are more suggestive than obligatory. They don’t come with a fixed deadline and are generally not a high priority for the organization. This type of deprecation is like expressing a wish for users to migrate to a new system without actively pushing them to do so. It’s about knowing a system has a better replacement but not enforcing a transition. These deprecations serve to inform users about the existence of a new, better system, hoping they’ll make the switch. However, for users to migrate, the benefits of the new system must be significantly compelling. Advisory deprecation can guide users towards better options, but it often lacks the power to effect substantial migration. At Google, experience suggests that advisory deprecation can lead to some reduction in the use of an obsolete system, but it rarely results in significant active migrations.

Compulsory Deprecation

In contrast, compulsory deprecation is more forceful, usually accompanied by a set deadline. After this deadline, the old system is no longer operational, which means users have to migrate to avoid disruption in their services. Scaling this effort effectively often involves consolidating expertise within a single dedicated team. For such deprecations to be effective, there must be an enforcement mechanism empowering the deprecation team to ensure compliance. However, compulsory deprecations can be challenging to execute, especially when critical infrastructure depends on the old system. Implementing these deprecations requires careful planning and staffing and often faces political and practical hurdles.

Deprecation Warnings

Deprecation warnings, crucial in both advisory and compulsory deprecations, need to be actionable and relevant. An effective warning should provide clear guidance on the next steps, surfacing at a time when it’s most useful to the user. Overusing deprecation warnings can lead to “alert fatigue,” where users start ignoring the warnings due to their sheer number. At Google, the approach is to mark old functions as deprecated while using tools like ErrorProne or clang-tidy to ensure that warnings are targeted and timely. This strategy helps in providing useful information without overwhelming the engineers.

Managing the Deprecation Process in Software Engineering

Deprecation is an essential but challenging part of software engineering, similar to constructing a system but with its own unique aspects. At Google, managing the deprecation process effectively requires clear ownership and strategic planning, much like any other software project.

Process Owners

The success of a deprecation process largely depends on having dedicated owners. Without explicit ownership, a deprecation initiative is likely to stagnate, regardless of the number of warnings or alerts generated. Assigning project owners to manage and oversee the deprecation ensures focus and direction, contrasting starkly with alternatives like indefinite maintenance of outdated systems or relying on users to transition themselves. Especially in larger organizations like Google, there are often projects still in use but lacking clear ownership or maintenance. In these cases, teams designated for deprecation, focusing solely on this task, are more effective than treating it as a side project.

Milestones in Deprecation

Unlike building new systems where progress can be measured incrementally, and each new feature adds value, deprecation can often feel like a journey towards a single goal: complete removal. This perception can make the process seem less rewarding until the final step is reached. To combat this, it’s beneficial to set and recognize incremental milestones in the deprecation process, similar to how achievements are celebrated in new product development. Recognizing steps like the deletion of a key subcomponent can boost morale and provide a sense of progress.

Deprecation Tooling

The tooling for managing deprecation typically falls into three categories: discovery, migration, and preventing backsliding.

• Discovery: Understanding who uses the old system and how it’s used is crucial in the early stages. Tools like Code Search and Kythe help identify users and dependencies. Runtime sampling and logging in production can reveal dynamic dependencies, and the global test suite acts as an oracle in ensuring all references to an old system are removed.
• Migration: The large-scale change (LSC) process and associated tooling play a significant role in updating the codebase to refer to new libraries or services.
• Preventing Backsliding: An often-overlooked aspect of deprecation is stopping the introduction of new dependencies on the system being deprecated. Tools like the Tricorder static analysis framework notify users when they are adding calls to a deprecated system, suggesting appropriate replacements. Compiler annotations on deprecated symbols and visibility whitelists in the build system also help in this regard.

In summary, managing the deprecation process in software engineering involves clear ownership, strategic planning with incremental milestones, and the effective use of various tools. These elements work together to facilitate the transition from old systems to newer, more efficient ones, ensuring that the deprecation process is smooth and the software ecosystem remains healthy and up-to-date.

Conclusion

Chapter 15, “Deprecation,” provides valuable insights into the world of software deprecation. It underscores the importance of managing aging software systems efficiently, highlights the challenges associated with deprecation, and offers strategies for successful execution. By recognizing when to phase out obsolete systems and implementing deprecation judiciously, software engineering can evolve and deliver greater value with reduced liabilities. Overall, this chapter serves as a comprehensive guide for modern software engineers navigating the complexities of software deprecation in a constantly evolving technological landscape.

This concludes the summary of Chapter 15, the last chapter in this series. Part III of the book delves into tools, offering further valuable insights. If you’re interested in a deeper understanding of Google’s software engineering practices, I encourage you to explore the entire book. I highly recommend purchasing the book to support the authors and gain a more comprehensive understanding of the subject matter, as the book provides a wealth of knowledge beyond these summaries. It’s a valuable resource for those seeking to enhance their software engineering skills and stay up-to-date with industry best practices.

Thank you for reading my post, and I hope it was useful for you. If you enjoyed the article and would like to show your support, please consider taking the following actions:

• 📚 If you found value in my articles and would like to support my work, consider buying me a book: Buy me a book
• 👏 Show your support by giving the article a clap, enhancing its visibility.
• 📖 Stay updated with my latest pieces by Follow Now.
• 🔔 Don’t miss out on my new posts. Subscribe to the newsletter.
• 🛎 For more regular updates, connect with me on LinkedIn.