I think I have a unique perspective on this, since I have both a strong CS training as well as a strong scientific computing training. I can look at code both f

I think I have a unique perspective on this, since I have both a strong CS training as well as a strong scientific computing training. I can look at code both from the perspective of producing useful scientific results as well as from the perspective of code quality (readability, maintainability, etc). Scientific computing is a unique problem in programming that is different from what I think software engineers are accustomed to solving themselves. Performance is often extremely important, it trumps almost everything; yet changes need to be made to the code frequently which often necessitates rewrites. The software engineer solution to this is abstraction: hide details of conceptually unrelated components so that changes can be made in isolation without needing to propagate them through the whole source. Unfortunately throw in things like paper deadlines and abstraction quickly becomes a contradictory goal to performance. Since the kinds of changes one needs to make to scientific code can rarely be predicted (it's research, by definition we don't know what the results are before we get them), spending a huge amount of time on an extensible framework almost always is a waste of time since we can't design it for the unknown (believe me, I have seen dozens of these and none of them have widespread adoption in research, despite being of very high "code quality."). Therefore an accepted practice is to write short hacks whose rewriting will be as painless as possible, if that is necessary. This is of course a generalization, not everybody does this. I'm just giving the reasoning behind this kind of code, and why modern practices are often ignored. The running assumption for this neglection is stubbornness or "get of my lawn" mentality from the researcher, but in my experience usually it's not.