There must be another more common term for this, but an older programmer once told me to watch out for "false parallelism" - code that is currently duplicated,

There must be another more common term for this, but an older programmer once told me to watch out for "false parallelism" - code that is currently duplicated, but is likely to diverge in the future, and so trying to make the code part of the same abstraction would not be meaningful. There's also the fact that with complex abstraction, you run into the problem that it can be more difficult to maintain as there's more layers of indirection. That cost of abstraction has been mentioned elsewhere, but I want to throw out there that both of these points fall under the umbrella of a powerful concept for writing maintainable code, that you should not only think about the best way to structure your code now, but you should consider how that code will change and how that structure will facilitate or hinder that. What I think I would have favored in this case would be to use some small, well-named utility functions that can be used to implement that math (not necessarily to replace all of it). I cannot see the code so I don't know for certain if utility functions would actually help, but I have taken this approach for geometry oriented code in the past and it worked well. In general, don't be afraid of writing small utility functions. I don't agree with the concept of letting "clean code" go. All he's done is replace "clean code" patterns with other ones that work better for the situation. What's best is becoming familiar with new patterns like the ones I've described above, not just "clean code" patterns, weighing their benefits and downsides for the current case, and not necessarily worry about whether you're using patterns that are arbitrarily part of a paradigm that hasn't worked in other cases (however, remaining aware that you don't know every pattern).