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?

  • 4
    If you're reading Scala for Data Science, that term appears exactly twice in the whole book, and one of them is in the index. The great search engine in the sky doesn't seem able to find that phrase anywhere else.
    – Blrfl
    Aug 18, 2017 at 23:44
  • 1
    What you are talking about sounds a lot like Abstractness in Abstractness vs. Instability metric.
    – Euphoric
    Aug 19, 2017 at 3:39
  • 4
    A more common term for the fancy "low on the permanence spectrum" would be "quick and dirty" . And it describes more of an intend at the time of writing then an actual trait. The funny thing is, in reality few things are as permanent as temporary solutions. Aug 19, 2017 at 6:32

2 Answers 2


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.

  • I think this is pretty good analysis but I think this might be a decent concept for communication. Sometimes developers will spend inordinate amounts of time trying to build a reusable solution when we need something quick to bridge the gap between solutions. Other times, I've seen things slapped together when something robust was needed. It's subjective but it might help everyone on a team understand what the plan is.
    – JimmyJames
    Aug 21, 2017 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.