> The colleague I mentioned earlier was new to the company and among other things that we spoke about, we seemed to disagree on whether or not it is a good idea

> The colleague I mentioned earlier was new to the company and among other things that we spoke about, we seemed to disagree on whether or not it is a good idea to introduce new patterns/paradigms into existing codebase. I am of the opinion that code should appear as though written by a single author even if it has been worked on by different people. His was that introducing newer patterns improves the quality of the code. While I agreed to an extent with him, I would vote against this if it violates the principle of least surprise[1]. Regarding that point, I disagree with you as well. To totally abstain from new patterns / paradigms make it easier for a codebase to become completely legacy to the point of needing a full rewrite. And full rewrites never happen [1]. In general, I favor reducing tech debt with gradual adaptation of new patterns supported by good unit tests and high test coverage for codebases in ongoing projects. Admittedly I have no idea the functionality or role of the specific codebase you're referring to, but that is my general philosophy. [1]: "Things You Should Never Do, Part I" by Joel Spolsky http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html