I sometimes see legacy systems as old cities: - The classic old town (the older parts of the system that tend to use older coding practices and technologies, b

I sometimes see legacy systems as old cities: - The classic old town (the older parts of the system that tend to use older coding practices and technologies, but have most of the bugs stamped out and more or less "just work") - The slums (the parts that tend to be bug prone, but are impossible to fix. I.e. no one wants to touch that code) - The apartments/row houses (parts of the code that involve lots of the same types of objects/classes/modules that follow a similar pattern) - The art district (the place where someone tried some odd/experimental libraries or code patterns) - The residential district with windy roads and lots of courts and loops (places in the code where there are lots of objects calling each other with really deep stack traces; easy to get confused where you are when debugging) Legacy systems are bound to have inconsistencies, but as you become more familiar with a system you begin to notice localized instances of consistency. These localized instances of consistency become the "districts" in our mental map of the system. To my mind, if you're working on mostly new code (within a large existing system) unless it is already a highly consistent code base I would just use whatever conventions make the most sense to the developers working on it.