One of the most common smells I see on projects is the desire to do things slightly differently for no good reason. Triggered by many different reasons such as new people joining a project, or when new functionality is being added, or when bugs need to be fixed. Each individual difference isn’t a problem on its own, rather it’s their accumulative effect that has a significant negative impact on projects that force developers to continually context switch when trying to match their mental model against the code or to navigate their way around a new area in the system. I find the death by a thousand differences is especially a significant problem on iterative projects where change happens rapidly such as the project Frankie describes.
Code isn’t the only thing that suffers from this condition as well with many unwarranted differences built into configuration and build and deployment scripts (ant, nant and msbuild).
What to do about it?
In many ways Rails had a very strong opinion that I agree with, following convention over configuration, with a core principle that every difference should exist for a good reason. Projects need code standards to help maintain consistency, and needs to be updated to reflect the current state of the system. New team members need to understand what the standard is, why it exists and the whole team needs to be vigilant against the additional context-switch each new difference adds.
Sometimes differences must exist, but always apply the 5 whys to question if the difference is really needed. Sometimes they exist as a means to an end (a transition to a better implementation pattern) yet projects must be wary that not too many differences exist at the same time without a good reason.
