Here's a more readable version I came across: https://gist.github.com/nwh/60eb3115754e68f2d1c46aa31961b660

> Accepting program modifications demanded by changing external circumstances to be an essential part of programming, it is argued that the primary aim of programming is to have the programmers build a theory of the way the matters at hand may be supported by the execution of a program. Such a view leads to a notion of program life that depends on the continued support of the program by programmers having its theory.

Agree with the theory of programming as theory*, but here's the problem with that essay in an era of software-as-a-services and platforms:

A SaaS offering or an Enterprise runs on a stack or assembly of software, each of which has its own Theory.

The problem with no churn is that most of the Theory is not in-house, it's elsewhere, and evolving. If you can't tap into that, you're falling behind. If you don't know it, you can't remix it into your own.

It's just math to convert an org's "refresh rate" of outside-in knowledge (aka churn) into the average lag of that organization behind current best theory and patterns. A 10% churn means an average of 5 years out of date. A 20% churn means at least a fifth of your org is 5+ years out of date.

A couple key antidotes, though (and there are of course more):

Realize that knowledge transfer from (a) outside in, then (b) among, is vital to theory maintenance and evolution.

That means (a) have a great "always be hiring" pipeline of fresh Theory and build processes to make knowledge sharing of outside and inside theory frictionless and routine, and (b) have a great "always be learning" approach to exposing developers not just to the internal theory but to the best and most up to date outside theory.

The better an org is at (b), the less it needs (a). The worse it is at (b), the more it needs (a), but -- crucially -- it must refresh with candidates who know more recent theory than the ones doing the hiring!

Churn is not bad, that word is spin. Internships are a thing, so are externships (firms should do more of this). People, and theories, grow by exposure to novel challenges. Circulation is good for the whole ecosystem of software development because we are building a collective Theory bigger than any one org.

This remixing of ideas is how our collective Theory evolves.

* Most recent decade of my career involved a lot of evangelizing to enterprise management that developers are not project teams to form and disband as fungible resources. Think in terms of capabilities to garden, not projects to remediate.

> This remixing of ideas is how our collective Theory evolves.

compare https://news.ycombinator.com/item?id=34315203 (and its wider context)