Balance Duplication, Disruption, and Paralysis - Revision history

Jhannes at 09:22, 23 July 2009

2009-07-23T09:22:08Z

←Older revision		Revision as of 09:22, 23 July 2009
Line 19:		Line 19:
	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 for 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 for 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 co-workers, 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, causing the very duplication we set out to cure. ~~In my experience,~~ domain objects are ~~particularly prone to being designed with insufficient extensiblility to be well-suited~~ for broad reuse.	+	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 co-workers, 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, causing the very duplication we set out to cure. Although domain objects are obvious candidates for broad reuse, I find that their reusable parts usually limit themselves to data fields, which means that reused domain objects often end up being very anemic.

	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.

Jhannes: Worked on the wording of "domain objects" paragraph

2009-07-20T16:54:49Z

Worked on the wording of "domain objects" paragraph

←Older revision		Revision as of 16:54, 20 July 2009
Line 3:		Line 3:
	''"Well, it looks like we only applied the fix to names of organizations, not names of individuals."''		''"Well, it looks like we only applied the fix to names of organizations, not names of individuals."''

-	If you duplicate code, it's not only effort that you duplicate. You also make the same decision about how to handle a particular aspect of the system in several places. If you learn that the decision was wrong, you might have to search long and hard to find all the places where you need to change. If you miss a place, your system will be inconsistent. Imagine if you remember to check for illegal character in some input fields and forgot to check in others?	+	If you duplicate code, it's not only effort that you duplicate. You also make the same decision about how to handle a particular aspect of the system in several places. If you learn that the decision was wrong, you might have to search long and hard to find all the places where you need to change. If you miss a place, your system will be inconsistent. Imagine if you remember to check for illegal character in some input fields and forgot to check in others.

	A system with a duplicated decision is a system that will eventually become inconsistent.		A system with a duplicated decision is a system that will eventually become inconsistent.
Line 11:		Line 11:
	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, thereby duplicating effort and 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 duplicate our code, thereby duplicating effort and understanding, and being forced to hunt down bugs twice. If there's only a few people in a team and you work on the same 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 the 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 share code and affect everyone who shares the code every time we change the 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.
Line 19:		Line 19:
	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 for 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 for 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 co-workers, 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, causing the very duplication we set out to cure. ~~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 co-workers, 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, causing the very duplication we set out to cure. In my experience, domain objects are particularly prone to being designed with insufficient extensiblility to be well-suited for broad reuse.

	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.

Kevlin at 05:23, 19 July 2009

2009-07-19T05:23:59Z

←Older revision		Revision as of 05:23, 19 July 2009
Line 1:		Line 1:
-	"I thought we had fixed the bug related to strange characters in names." ~~"Well, it looks like we only applied the fix to names of organizations, not names of individuals."~~	+	''"I thought we had fixed the bug related to strange characters in names."''

-	If you duplicate code, ~~you don~~'t only ~~duplicate~~ effort. You also make the same decision about how to handle a particular aspect of the system several places. If you learn that the decision was wrong, you might have to search long and hard to find all the places where you need to change. If you miss a place, your system will be inconsistent. Imagine if you remember to check for illegal character in some input fields and forgot to check in others?	+	''"Well, it looks like we only applied the fix to names of organizations, not names of individuals."''
		+
		+	If you duplicate code, it's not only effort that you duplicate. You also make the same decision about how to handle a particular aspect of the system in several places. If you learn that the decision was wrong, you might have to search long and hard to find all the places where you need to change. If you miss a place, your system will be inconsistent. Imagine if you remember to check for illegal character in some input fields and forgot to check in others?

	A system with a duplicated decision is a system that will eventually become inconsistent.		A system with a duplicated decision is a system that will eventually become inconsistent.

-	This is the background for the common programmer credo "Don't Repeat Yourself," as the Pragmatic Programmers say, or "Once and only once," which you will hear from Extreme Programmers. It is important not to duplicate your code. But should you duplicate the code of others?	+	This is the background for the common programmer credo "Don't Repeat Yourself," as the Pragmatic Programmers say, or "Once and only once," which you will hear from Extreme Programmers. It is important not to duplicate your code. But should you duplicate the code of others?

-	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 only a 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, thereby duplicating effort and 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 share code and affect everyone who shares the code every time we change the 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.	+	* We can keep shared code unchanged, 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 for 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, causing the very duplication we set out to cure. 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 co-workers, 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, causing the very duplication we set out to cure. 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.

Kevlin: Balance duplication, disruption and paralysis moved to Balance Duplication, Disruption, and Paralysis

2009-07-19T05:06:10Z

Balance duplication, disruption and paralysis moved to Balance Duplication, Disruption, and Paralysis

←Older revision

Revision as of 05:06, 19 July 2009

Jhannes: Added more about duplication

2009-04-09T14:43:34Z

Added more about duplication

←Older revision		Revision as of 14:43, 9 April 2009
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 sound bites, we risk following it even when it~~ is not ~~appropriate~~.	+	"I thought we had fixed the bug related to strange characters in names." "Well, it looks like we only applied the fix to names of organizations, not names of individuals."
		+
		+	If you duplicate code, you don't only duplicate effort. You also make the same decision about how to handle a particular aspect of the system several places. If you learn that the decision was wrong, you might have to search long and hard to find all the places where you need to change. If you miss a place, your system will be inconsistent. Imagine if you remember to check for illegal character in some input fields and forgot to check in others?
		+
		+	A system with a duplicated decision is a system that will eventually become inconsistent.
		+
		+	This is the background for the common programmer credo "Don't Repeat Yourself," as the Pragmatic Programmers say, or "Once and only once," which you will hear from Extreme Programmers. It is important not to duplicate your code. But should you duplicate the code of others?

	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.
Line 11:		Line 17:
	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, causing the very duplication we set out to cure. 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.

Kevlin at 08:09, 17 February 2009

2009-02-17T08:09:22Z

←Older revision		Revision as of 08:09, 17 February 2009
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]]

Jhannes: Initial version (imported from blog)

2009-02-16T18:19:30Z

Initial version (imported from blog)

New page

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.

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 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 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.

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 [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Back to [[97 Things Every Programmer Should Know]] home page