On every medium to large software system, consistency becomes critical.
By consistency I mean the application of certain architectural patterns that are considered the standard way of "doing things" in a software organization. Consistency helps keep the system understandable to all programmers currently involved, and to those that may come in the future. Consistency also helps when solving known problems as established patterns can be applied with ease. Consistency attempts to keep the entropy of the system under control.
On the other hand, it can also make improving a system hard. How can you change the standard without introducing inconsistencies? In a large project there is probably no good reason to change existing code that is already working for new code that does the same in a different way. No matter how better the new approach is; it just isn't cost effective.
In my opinion, consistency can not be taken in an absolute way. Consistency is never a good reason not to improve a design. If this wasn't true there would be no legacy code ever. Instead new valuable ideas should be embraced and considered the new consistent way. No new code should be written following the old way. Changing the old code should be considered technical debt if it merits the effort which very likely it will. Resistance to changes that improve the quality of a system overall is irresponsible.
How is this issue dealt with in your organization? Is consistency used as a reason to reject changes?
