The intersection of technology and leadership

Death by a thousand differences

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.

1 Comment

  1. Kris Kemper

    I actually find that allowing differences to happen is generally a good thing on a project. It allows developers freedom to try different approaches. This results in greater enjoyment of the work, but it also provides different approaches to be compared in order to see what really works in practice.

    I find that the differences can be reduced by refactoring. Once the team has a general consensus of what has gone well versus what does not work well, then the “bad” code can be refactoring using the accepted practices. The important thing is that refactoring has to be an constant activity on the team, and accepted as a necessary and valuable activity.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2024 patkua@work

Theme by Anders NorenUp ↑