PepsiCo

Karthik Sankaran

Software Architecture Authority

On June 4, 1996, the maiden flight of the Ariane 5 rocket ended about 30 seconds after liftoff over Kourou, French Guiana. Four satellites and roughly $370 million were lost. The inquiry traced the failure to software reused from Ariane 4.

The code was not sloppy. It was well-written, extensively tested, and flight-proven. But buried inside was an assumption about how fast the rocket would move sideways. Ariane 5 flew a different trajectory, producing a horizontal-velocity value the software could not handle. The resulting failure caused the rocket to veer off course and break apart. The reused code carried assumptions from another rocket. A component that is reliable in one environment can fail in another because the context has changed.

When the Old Economics Made Sense

For decades, the case for reuse looked obvious. Code was expensive to produce, so writing something once and sharing it everywhere beat building it again and again. Generative AI has changed that arithmetic. AI-assisted development is lowering the cost of producing code, while coordination, contextual judgment, verification, and delayed decisions remain costly. Organizations with strict reuse mandates may be optimizing a shrinking cost while increasing coordination costs.

Software reuse remains essential. Few organizations benefit from reinventing cryptography or deployment pipelines, and sharing capabilities within a domain or through a stable interface often makes sense. The concern is mandated sharing of a single implementation across contexts whose differences affect its behavior. Problems arise when reuse becomes a goal in itself rather than a choice judged by its consequences.

Every shared component avoids some implementation work and creates some coordination work. The avoided work shows up cleanly as fewer components and less duplicated code. The coordination cost surfaces later, through alignment meetings, platform backlogs, synchronized releases, migrations, and exceptions. As AI lowers coding costs, reuse creates value only when its savings exceed the less visible costs of coordination, complexity, and dependency.

Reuse Transfers Context, Not Just Capability

In the same year that Ariane 5 failed, the United States launched the Joint Strike Fighter program. The premise was appealing: the Air Force, Navy, and Marine Corps would share one aircraft family instead of building three. Early projections assumed that heavy commonality would cut costs. The services did not need the same aircraft. Conventional runway operations, carrier landings, and short-takeoff-and-vertical-landing capability imposed different demands. As the differences surfaced, commonality fell and the savings eroded. RAND later concluded that historical joint aircraft programs had not delivered lifecycle savings over single-service programs.

 ​As AI lowers the cost of coding, software reuse creates value only when its savings exceed the less visible costs of coordination, complexity, and dependency. 

The case for commonality looks strongest before the consequential differences are understood. At a high enough level of abstraction, unlike needs look identical. Three business units all want “risk assessment.” Then one needs a decision in seconds, another requires human approval, and a third works under a different legal definition of risk. The common component fills with switches and policy layers until it is harder to maintain than several focused builds. Reuse decisions are often made while requirements exist only as abstractions. The consequential differences, and their costs, emerge during implementation and after deployment.

The Doorman Fallacy

Rory Sutherland asks readers to imagine a hotel that hires consultants to cut costs. They define the doorman’s job as “opening the door,” replace him with a machine, and book the savings. The analysis misses the security, prestige, taxi-hailing, and welcome he provides. Remove him, and the hotel may become less distinctive and less able to justify its premium price. The spreadsheet records the saving but not the value the business has lost. Reuse business cases make the same mistake. They count shared code, avoided licenses, and retired components. They rarely count features that are bent to fit a common abstraction, months spent waiting for another team, experiments never attempted, or customer value never discovered.

The Coordination Tax Becomes an Ownership Problem

Every shared component creates a shared dependency. Each new consumer adds a requirement to protect, and each change acquires a larger blast radius. A shared service that begins as a shortcut gradually becomes a negotiation. It also splits ownership. The application team stays accountable for the customer outcome but has no agency over the central component, while the platform team has agency but does not own any single product’s results. Responsibility is split: one group decides, another lives with the consequences, and neither fully owns the result. Developer frustration in this model is not simply a preference for homegrown code. It is what happens when teams are held accountable for outcomes they lack the authority to change.

Standardize the Container, Not the Cargo

In 1956, a converted tanker, the Ideal X, sailed from Newark with 58 metal containers and helped launch modern shipping. The breakthrough was an agreement on the boundaries: dimensions, strength, corner fittings, and handling. The standard never dictated what went inside. Trade scaled because participants standardized the interface, not the contents.

Enterprise software can work the same way. Centralize what can be specified without losing meaning: identity, security, data contracts, observability, and deployment controls. Preserve local authorship where integrated judgment creates value, close to the teams that own the outcome. A paved road earns adoption because it is easier and safer to travel, not because every other route has been blocked.

Before mandating a shared implementation, leaders should ask whether the capability is truly common or merely appears to be so at a high level, whether the business case counts the coordination tax, and whether the decision is reversible if a cheaper, fit-for-purpose option becomes feasible.

Reuse remains one of software engineering’s most valuable ideas. It deserves to be treated as an economic and organizational choice, not a virtue measured by the absence of duplicate code.

The strongest architecture in the AI era may not have the fewest implementations. It should standardize the components that manage enterprise risk while preserving local authorship where differences create advantage.