Bit rot vs Re-usable code

The intellectual property in a software company is diffuse. The explicit IP can be found in patents, papers, documents and, above all, the code base. The tacit IP exists in people's heads.

It is the tacit IP that allows for innovation and change. Indeed, a good way of understanding the possibility of change is the extent to which the maintainers of the software have a theory of how it works. If they do, they can change and extend it. If they cannot they are likely damaging the conceptual integrity of the code-base.

In The Worthlessness of Code James Turner advocates regularly rewriting to ensure that the software development team understands what they are working with, and in-particular, so that the original designers effectively refresh and transfer their knowledge to new hires.

In the comments the rebuttals of "continuous re-writing", and "re-usable code" are raised. Personally, I sympathize with Turner. I used to have a motto: Before re-use, use. This mocked the scenario of people trying to writing libraries or frameworks that would be used multiply, before being deployed successfully even once. Oy! The better alternative is to extract, abstract and generalize after an initial success or two.

What about libraries? The good ones do have a long life. This comment from the Reddit comments on Turner's article draws an important distinction:

How about "reusable code is an asset, single-use code is a liability"?

I like this idea. There is the abstracted, cleaned stuff that ends up in libraries, and gets re-used, and there is the more scripty stuff that glues things together and gets the short-term job done.

This raises the possibility of a new, somewhat informal metric: Ratio of multiple-use (quality code) to single-use (get-it-done code).