Why cleaning up is harder than it looks

Every large organization eventually faces the problem of retiring a product that has outlived its usefulness. Meta’s Moments app, launched in 2015 and deprecated in 2019, is one such example. The challenge is not deciding to shut something down, but doing it without breaking anything else in a portfolio of thousands of interconnected features.

Attempting this cleanup without established guidance leads to recognizable failure modes. An engineer might keep an event-specific feature around indefinitely rather than rebuild it for the next occurrence, simply because removal is daunting. Or a cleanup effort might go wrong by including assets that are still in use. Tables and code are frequently shared between products—a feature that starts as an extension of an existing product before becoming a standalone app can leave entanglement behind. The worst outcome is deleting something that is still live in production, which can directly harm the user experience.

SCARF: A guided path through deprecation

Meta’s answer is the Systematic Code and Asset Removal Framework (SCARF). SCARF does not replace the company’s existing playbooks for deprecation—those cover user notification, data download periods, and safe product disabling. Instead, it provides an engineering solution that makes the actual deletion of code and data safer and more efficient.

The workflow management tool inside SCARF lets an engineer import a product or feature. SCARF then determines the constituent pieces of code and data, and identifies both internal and external dependencies on those assets. It processes this information to produce a recommended order of operations for deletion, and tracks progress toward the desired end state.

The tool only asks engineers to make decisions at the boundaries: either flag a dependency that should be severed, or add an asset to the project scope. Everything inside the project is automatically analyzed to compute the correct deletion order. Assets that are safe to delete immediately are handled by SCARF’s automated cleanup systems, while the engineer can accelerate the process using domain knowledge combined with SCARF’s scoping analysis.

Scoping is an iterative process. If a product has an integration with a shared feature—for example, a Facebook Sharing integration that is not unique to the product being deprecated—that dependency is flagged and severed rather than deleted. If, however, the integration component only exists to serve the departing product, it should be added to the scope and removed. Because dependencies change as the engineer discovers new components, SCARF allows the project boundary to be redefined throughout the deprecation rather than demanding a final scope up front.

Sequenced deletion with a daily roadmap

SCARF generates a deletion roadmap that outlines the correct sequence of steps for removing everything in the project safely. This roadmap is refreshed daily, reflecting both completed deletions and any changes to the component graph from flagging or adding assets. The sequencing matters because deletions cannot typically be committed atomically across system boundaries. Deleting data before the code that reads and writes it, for instance, only results in new data being created that has to be cleaned a second time.

The roadmap is built on encoded business logic that describes how products and apps function within Meta’s systems. The typical sequence moves from client code in languages like Java and Objective-C, to server-side GraphQL definitions, to business logic, to data schema definitions, and finally to the unused data itself. These boundaries between systems are often weaker than the links between classes within a single language, and may only be discovered during testing. Making that inter-system logic explicit lets engineers stagger their removal actions safely rather than trying to delete an entire code directory at once.

Metrics drive the automation

SCARF’s workflow management tool is backed by metrics from static and dynamic analysis. Code information comes from a unified code dependency graph; data information comes from SCARF’s asset usage analysis. These metrics provide a completeness property: if a metric exists for an asset, the asset is in use and is blocked from automated deletion. If no metric exists, the asset is ready for automatic removal.

That gives engineers a precise view of what is blocking the automation and what manual steps are required to proceed. When the engineer removes more assets following the deletion roadmap, SCARF’s continuous indexing detects the changes, triggers any applicable cleanup, and updates the roadmap to identify the next items needing manual intervention.

The impact has been substantial. In the last year, SCARF removed petabytes of unused data across 12.8M data types stored in 21 different data systems. Over five years, it has deleted more than 100M lines of code. How the framework automates dead code removal and orchestrates safe data type deletion across those systems are topics this series covers next.

Human judgment still has a role

Not every usage signal SCARF detects is a hard blocker for removal. Signals like API endpoints still receiving traffic don't necessarily cause compilation errors if ignored, and deciding whether such activity should halt deletion is ultimately subjective. A single daily request to an endpoint tied to a product slated for removal doesn't automatically answer the question of when deletion is safe—that's a business call. Since a mistaken deletion could lead to unrecoverable errors or data loss, SCARF deliberately errs on the side of caution.

To accommodate this, SCARF allows engineers to override signals that would otherwise prevent automation from proceeding. In practice, this means an engineer can choose to delete an API endpoint even when small amounts of traffic remain. This capability proves especially valuable for internal products, tools, and services, which are built and deprecated at a much faster cadence than external offerings. SCARF can identify each individual internal user of a tool who should be consulted before removal.

This design establishes a feedback loop between engineers and automation. SCARF surfaces usage signals; engineers triage them by either modifying code to eliminate the signal or marking it as insufficient to block deletion; automation then continues progressing the SCARF project.

To speed up the manual side of that loop, SCARF offers an instant code change feature. When SCARF suggests a way to break a dependency through a targeted code change, an engineer can pick from a predetermined set of possible approaches. The change is immediately previewable, and a change request can be generated on the spot for review by other engineers.

Once an engineer has worked through most of the deletion roadmap—removing entry points, client code, server code, and other in-scope assets—they are left with unused data tables that SCARF can clean up automatically. That automation is the subject of future posts in this series.

Beyond deprecation: SCARF in routine maintenance

SCARF's utility extends past product deprecation. The tool surfaces deprecation as an option when notifying engineers about routine maintenance or upgrade work on individual assets. For example, when developers are asked to migrate away from a legacy internal API, they can choose to deprecate the call site or affected product and import their code into SCARF instead. Deprecation can sometimes require more work than a simple upgrade, but it eliminates all future maintenance costs—once something is removed, upkeep goes to zero.

Subsequent posts in this series cover SCARF's automated code cleanup and automated data deletion features.