I read in a data science book that there is the concept of a code permanence spectrum. If your code is low on the permanence spectrum the code is ad-hoc/throw away work. I work mostly as a scientist where the code is my tool for doing analysis. However, I've noticed from studying some of my colleague's code that there are many reusable components and that writing in sufficient abstraction does provide some generic reusability. I'm wondering what a computer scientist's perspective (and a software architect's) perspective is with respect to the notion of code permanence spectrum?
Apparently unique terminology notwithstanding (as per above comments), reusability is certainly a valuable design consideration in pretty much every development effort. Whenever possible, and as much as feasible, you should decompose an application into functional components whose external input/output behavior is abstractly meaningful, succinct, and likely reusable.
Take the C library function strcpy(target,source) as an example. If it didn't exist, and you came across a situation where you needed to copy a string, you could accomplish that several ways. Right at the point where you needed it, you could just write a little loop. Fine and dandy, and you're all done. Alternatively, you could say to yourself, "I've had to do this sort of thing many times before. Maybe I should take a few more minutes and write a separate function that encapsulates the general idea. Then next time I need it, no more little loops. Just call that function and I'm done."
For simple and straightforward and obviously-reusable functions like strcpy(), its abstraction as a separate function doesn't take much intellectual insight. However, it sometimes takes great insight to factor a large and complicated application in such a way that its decomposition maximizes the reusability and simplicity of its functional components. So that's a definitely worthwhile and challenging task, which can also be very satisfying when successfully accomplished.
And in my personal experience, despite investing time and effort, I've never completely successfully accomplished it in the first release of any non-trivial project. In other words, given the opportunity to go back and do it again, I'd do it at least slightly differently, and sometimes very differently. And I sometimes have had those opportunities, usually when new or modified functionality is requested. Whenever time/budget's available, I try to add ~15% overhead to improved re-design/coding.
And changed functionality frequently reveals better decomposition that hadn't been originally evident (at least not to me). Perhaps it's analogous to cutting up a picture into a jigsaw puzzle, in such a way so that many identical copies from a small number of different pieces can reconstruct the entire picture. Then, if somebody adds or changes a little of the picture, your optimal selection of jigsaw pieces is likely to change in some corresponding way.
Speaking from a development point of view, it is well understood that code is sometimes written in a quick and dirty way to get something working. At the other extreme is well designed, well written code that reaches a level of maturity over a period of time.
IMHO, these extremes do not a spectrum make. What appears (at first glance) to be throw away code run in an ad hoc manner may have been refined a large number of times. While what appears to be a mature software product may contain some relatively untested, unrefactored, duplicated code that could be improved vastly given some time and effort.
The concept has some merit, but I feel it vastly over simplifies what goes on in the real world. Furthermore, from a development point of view, even if there was a spectrum, knowing where the software sat on it (this itself, being highly subjective) is a bagatelle compared to other concerns.