Sometimes it's right to be wrong
I have recently been part of a team bug-fixing and extending a huge distributed system that has been in constant development for several years. The hardest problems we had in understanding this code was a lack of consistency - different classes that had similar responsibilities all performed those responsibilities in significantly different ways. Some of the code was pretty awful and needed refactoring, but everybody who had added to the system had had their own ideas of the "right" way in which things should be done. The end result was that there no longer was a right way to do things, just lots of wrong ways.
When writing code that must be maintained by others it is better to be consistently wrong than to be inconsistently right. For example, if you have to modify a large codebase in a limited amount of time and your changes affect code that is poorly designed you have three options:
- Refactor the rest of the codebase to work the way you think it should, and then make your changes.
- Write your code to work in the same way as the rest of the codebase, even though it's not the best way it could be done.
- Write your changes in the way you think is best, despite what the rest of the code does, and leave the rest of the code untouched.
When pressed for time the first option is not practical, but the second option just propagates bad design decisions. No matter what the situation, however, the third option is always the wrong choice.
If you cannot refactor, be consistent. Consistency makes code easier to understand and maintain, even if the code is consistently awful.