Balance Duplication, Disruption, and Paralysis

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Initial version (imported from blog))
Line 1: Line 1:
-
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 credos, we risk following it even when it is not appropriate.
+
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.
+
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 few people in a team and you work on the problem, eliminating duplication should almost always be way to go.
+
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 might’ve experienced code storms: Days where you’re unable to get any work done as you’re chasing the consequences of other people’s changes.
+
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 unchanging, thus forgoing improvements. 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.
+
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.
+
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.
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.
+
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]]
By [[Johannes Brodwall]]

Revision as of 08:09, 17 February 2009

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