Balance Duplication, Disruption, and Paralysis

From WikiContent

Revision as of 08:09, 17 February 2009 by Kevlin (Talk | contribs)
Jump to: navigation, search

A common programmer credo is "Don't Repeat Yourself," as the Pragmatic Programmers say, or "Once and only once," which you will hear from Extreme Programmers. Like all sound bites, we risk following it even when it is not appropriate.

The larger truth is that we have choice between three evils: duplication, disruption and paralysis.

We can duplicate our code, thus duplicating effort, understanding and being forced to hunt down bugs twice. If there's only a few people in a team and you work on the problem, eliminating duplication should almost always be way to go.

We can share code and affect everyone who shares the code every time we change to code to better fit our needs. If this is a large number of people, this translates into lots of extra work. If you're on a large project, you may have experienced code storms — days where you're unable to get any work done as you're busy chasing the consequences of other people's changes.

We can keep shared code unchanged, thus forgoing any improvement. Most code I (and, I expect, you) write is not initially fit for its purpose, so this means leaving bad code to cause more harm.

I expect there is no perfect answer to this dilemma. When the number of people involved is low, we might accept the noise of people changing code that's used by others. As the number of people in a project grows, this becomes increasingly painful to everyone involved. At some time, large projects start experiencing paralysis.

The scary thing about code paralysis is that you might not even notice it. As the impact of changes are being felt by all your coworkers, you start reducing how frequently you improve the code. Gradually, your problem drifts away from what the code supports well, and the interesting logic starts to bleed out of the shared code and into various nooks and crannies of your code. This seems to happen especially frequently with domain objects, which often aren't designed to be extensible.

If we're not happy with the state of the code when paralysis sets in, it might be that there's really only one option left: To eschew the advice of the masters and duplicate the code.

By Johannes Brodwall

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools