I 95% agree with this article, but think that 5% is an important disagreement. Background: I spent most of the last decade writing, maintaining, and managing a

I 95% agree with this article, but think that 5% is an important disagreement. Background: I spent most of the last decade writing, maintaining, and managing a large enterprise app that had to evolve from its .NET 1.1 foundations to the present day. Our code base looked almost precisely like the one talked about in that article, and with the very real problems mentioned there. But... 1. Sometimes the productivity wins of a new approach are serious enough that it's worth taking the consistency hit. I'd argue that ORMs, for instance, really are worth it compared to the quasi-code-gen ADO.NET layer. Switching to those midway through the project introduced inconsistency, but all future development done with the ORM was much faster (and more reliable) than the stuff done with the old approach. (And yes, this is a dangerous argument, because it's easy to convince yourself that it's true all the time, if you want an excuse to use a new technology. But if applied skeptically, it really is true sometimes.) 2. Developer morale is a thing. "You can only use technology invented in 2003, none of this fancy .NET 2.0 stuff, and haha LINQ, are you kidding me?" is going to crush people's spirits, whereas "sure, let's try this new module out using ASP.NET MVC" will introduce an inconsistency into the codebase, but will keep developers more engaged and learning new things (and who knows, maybe this experiment will prove to be one of those ones that gives you a big productivity win). You have to be careful with that, because you can't literally try out every crazy new thing, but you also can't ignore everything new in the name of consistency and expect anyone to want to work on the project.