Regenerative Software

Chapter 3. The Seven Primitives: How the System Survives the Implementation

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 3rd chapter of the final book.

If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at [e-mail].

In Chapter 1, I argued that code isn’t the asset. The system is. That sounds fine until you try to delete something. Then the question gets uncomfortable: if the system isn’t the code, where does the system live?

I’ve spent a lot of years watching system replacements fail, and the failures have a pattern.

A team rewrites a payment service. The new implementation passes the tests and deploys cleanly. Six months later, a compliance auditor asks why a particular rounding rule exists. The code is right there. It still rounds correctly. But the reason is gone. The regulatory requirement that created the rule is gone. The rejected alternatives are gone. The payment processor constraint that made the ugly version necessary is gone.

Another team replaces a rate limiter. The new version rejects the same requests as the old one, but takes 200 milliseconds to do it. That sounds fine until three upstream services start timing out. The old implementation had rejected requests in under 50 milliseconds, ...