The half-life of internal frameworks

Every internal framework is born as an accelerant and dies as archaeology, and the interval between is set less by the code than by a staffing table. Call it the half-life: the time until half the people who understand the framework's decisions no longer work on it. Most organizations never estimate this number, and then are surprised by a decay process they funded personally.

The lifecycle is regular enough to narrate. Year one: a strong team extracts a framework from two successful projects, and it is genuinely good, because it encodes fresh, hard-won knowledge. Year two: adoption, evangelism, the internal conference talk. Year three: the authors are promoted, or leave, or found the platform team. Year four: the framework is a dependency that every new project takes by default and no current employee can modify with confidence. Year five: a new strong team, blocked by the framework weekly, extracts a new framework from two successful projects. The cycle is not a failure of any individual; it is what half-lives do.

The economics are asymmetric in a way the year-one business case never states. A framework's benefits are front-loaded (velocity now, consistency now) while its costs are back-loaded onto people who did not choose it: the upgrade that the framework blocks, the hire who must learn an unGoogleable stack, the security patch that must be threaded through an abstraction its author no longer remembers. Google's engineering-practice book makes the general form of this point with a phrase worth framing: software engineering is programming integrated over time. Internal frameworks are where the integral goes to be underestimated.

None of this argues for zero internal frameworks; it argues for pricing the half-life in. Three questions do most of the work. Who maintains this in year four, by name or by charter, and is that funded? What is the exit, meaning how does a team leave the framework without a rewrite, and has anyone rehearsed it? And the sharpest one: does this framework encode our domain, or our current taste? Domain knowledge (how this company calculates settlement risk) ages slowly and deserves owned code. Taste (how we prefer to route HTTP this year) ages like fruit, and the open-source commons will maintain the tasteful version with ten thousand unpaid hands.

There is a respectable middle path that gets less airtime than either extreme: the thin wrapper with an expiry date. Wrap the open thing narrowly, document that the wrapper exists to be deleted, and review the deletion annually like any other deprecation. Teams that practice this keep the benefit of consistency while paying maintenance only on the seam.

The half-life, once you start estimating it, turns out to be shorter than intuition suggests: three to five years in most shops, tracking tenure curves almost exactly. Write the framework anyway, when the domain justifies it. Just write the funeral into the same document as the launch, and the organization will be spared the usual decade of pretending the decay is a surprise.