Consistency vs Design Guidelines

Question

Lets say that you get involved in the development of a large project that is already in development for a long period ( more than one year ). The projects follows some of the current design guidelines, but also has a few different, that are currently discouraged ( mostly at naming guidelines ).

Supposing that you can't/aren't allowed to change the whole project:

What should be more important, consistency, follow the existing ones and defy current guidelines or the usage of the guidelines, creating differences between modules of the same project ?

Thanks.

Answer 1

As always, it depends.

If it's a project you're going to be working on for a long time, it's worth making changes or introducing improvements to achieve consistency. For projects with a shorter lifespan, I wouldn't bother.

Usually this question is better asked to those who invented the guidelines though - it could be noted in the guidelines that "existing applications are grandfathered in, but new modules have to follow at least ..." or something.

Answer 2

Consistency all day. (Unless everything is consistently bad, then I find a new project!)

Answer 3

Generally, I would favour consistency. But sometimes there are strong reasons for preferring the evolved style. Perhaps the initial standards were found to be ineffective, or simply imposed too great an overhead. It may be excessive to go back and retrofit the changes but to continue to follow what is now known to be a bad practice in the name of consistency I see as a bad decision.

A specific example: 30 person, three year project. Our standards sai to put some particualr documentation before each method (don't remember the details, think it was a list of messages that could be logged or some such.) This was found to be a lot of work to maintain and was never used, because we had a code munger to produce the definitive list of message origins. We simply stopped adding the information to new methods, no time to got and tidy the entirity of the code base.

Answer 4

I'd lean more towards being consistent within the project, but if at all possible convince the "higher-ups" that the refactoring would be minimal (if it's truly just naming conventions) as well as would make maintainability easier since this program would be consistent with other past/future projects.

Answer 5

Supposing that you can't/aren't allowed to change the whole project:

Stick to the consistency but if you team and management is open to suggestion, do discuss this with them as a proper conversation would add a lot to your upcoming projects.

Answer 6

A great question and a tough issue to deal with.

I've seen a project where several tech leads followed one another, each bringing his own architecture and coding guidelines to the new features that were developed but keeping the existing code intact. This resulted in a cluttered, disparate code base where every module differed from the others, making the whole thing very awkward to comprehend.

If you can refactor the existing code according to your new guidelines (and if the rest of the team is OK with that), then you should absolutely do it.

Otherwise just stick to the current coding practices as long as they don't breed a technical debt that would grow uncontrolled in the future.