The Longevity of Interim Solutions - Revision history

Kevlin at 06:11, 7 August 2009

Kevlin — Fri, 07 Aug 2009 06:11:18 GMT

←Older revision		Revision as of 06:11, 7 August 2009
Line 23:		Line 23:
	Let's examine these options more closely:		Let's examine these options more closely:

-	# Avoidance does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. ~~A honourable~~ albeit tedious endeavor... and that change will not be effective in time for your problem at hand.	+	# Avoidance does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. An honorable albeit tedious endeavor... and that change will not be effective in time for your problem at hand.
-	# The forces are rooted in the project culture, which resists volitional ~~changes~~. It could be successful in very small projects — ~~in particular~~ if it's just you — and you just happen to clean the mess without asking in advance. It could also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.	+	# The forces are rooted in the project culture, which resists volitional change. It could be successful in very small projects — especially if it's just you — and you just happen to clean the mess without asking in advance. It could also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.
	# The status quo automatically applies if the previous option does not.		# The status quo automatically applies if the previous option does not.

-	You will create many solutions, some of them will be interim, most of them will be useful. The best way to overcome interim solutions is to make them superfluous, to provide a more elegant and useful solution. May you be granted the serenity to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference. ~~[1]~~	+	You will create many solutions, some of them will be interim, most of them will be useful. The best way to overcome interim solutions is to make them superfluous, to provide a more elegant and useful solution. May you be granted the [http://en.wikipedia.org/wiki/Serenity_prayer serenity] to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference.

	By [[Klaus Marquardt]]		By [[Klaus Marquardt]]
Line 37:		Line 37:

	Back to [[97 Things Every Programmer Should Know]] home page		Back to [[97 Things Every Programmer Should Know]] home page
-
-	[1] http://en.wikipedia.org/wiki/Serenity_prayer

Kmarquardt at 12:24, 24 July 2009

Kmarquardt — Fri, 24 Jul 2009 12:24:11 GMT

←Older revision		Revision as of 12:24, 24 July 2009
Line 1:		Line 1:
-	In most systems and teams you will find software that is somewhat dis-integrated from the system, that is considered a draft to be changed sometime, and you will hear developers complaining about these. The drafty, interim solutions that we create have a much longer life than we assumed.
-
	Why do we create interim solutions?		Why do we create interim solutions?

	Typically there is some immediate problem to solve. It might be internal to the development team, some tooling that fills a gap in the tool chain. It might be external, visible to end users, such as a workaround that addresses missing functionality.		Typically there is some immediate problem to solve. It might be internal to the development team, some tooling that fills a gap in the tool chain. It might be external, visible to end users, such as a workaround that addresses missing functionality.

-	~~An interim solution~~ is ~~not fully~~ integrated ~~into~~ the ~~production code~~, or does not follow the standards and guidelines that shaped the rest of the code. The reasons are many and varied, but the key to an interim solution's success is simple: It is useful.	+	In most systems and teams you will find software that is somewhat dis-integrated from the system, that is considered a draft to be changed sometime, that does not follow the standards and guidelines that shaped the rest of the code. Inevitably you will hear developers complaining about these. The reasons for their creation are many and varied, but the key to an interim solution's success is simple: It is useful.

	Interim solutions, however, acquire inertia (or momentum, depending on your point of view). Because they are there, ultimately useful and widely accepted, there is no immediate need to do anything else. Whenever a stakeholder has to decide what action adds the most value, there will be many that are ranked higher than proper integration of an interim solution. Why? Because it is there, it works, and it is accepted. The only perceived downside is that it does not follow the chosen standards and guidelines — except for a few niche markets, this is not considered to be a significant force.		Interim solutions, however, acquire inertia (or momentum, depending on your point of view). Because they are there, ultimately useful and widely accepted, there is no immediate need to do anything else. Whenever a stakeholder has to decide what action adds the most value, there will be many that are ranked higher than proper integration of an interim solution. Why? Because it is there, it works, and it is accepted. The only perceived downside is that it does not follow the chosen standards and guidelines — except for a few niche markets, this is not considered to be a significant force.
Line 15:		Line 13:
	Is this a problem?		Is this a problem?

-	The answer depends on your ~~mileage~~ and your stake in the production code standards. When the systems contains too many interim solutions, its entropy or internal complexity grows and its maintainability ~~decreses~~. However, this is probably the wrong question to ask first. Remember that we are talking about a solution. It may not be your preferred solution — it is unlikely to be anybody's preferred solution — but the motivation to rework this solution is ~~too~~ weak.	+	The answer depends on your project, and on your personal stake in the production code standards. When the systems contains too many interim solutions, its entropy or internal complexity grows and its maintainability decreases. However, this is probably the wrong question to ask first. Remember that we are talking about a solution. It may not be your preferred solution — it is unlikely to be anybody's preferred solution — but the motivation to rework this solution is weak.

	So what can we do if we see a problem?		So what can we do if we see a problem?
Line 25:		Line 23:
	Let's examine these options more closely:		Let's examine these options more closely:

-	# Avoidance does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. ~~Apart from starting a~~ tedious endeavor ~~with unclear outcome, it~~ will ~~only~~ be effective for ~~some future interim solution, not for yours~~.	+	# Avoidance does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. A honourable albeit tedious endeavor... and that change will not be effective in time for your problem at hand.
	# The forces are rooted in the project culture, which resists volitional changes. It could be successful in very small projects — in particular if it's just you — and you just happen to clean the mess without asking in advance. It could also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.		# The forces are rooted in the project culture, which resists volitional changes. It could be successful in very small projects — in particular if it's just you — and you just happen to clean the mess without asking in advance. It could also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.
	# The status quo automatically applies if the previous option does not.		# The status quo automatically applies if the previous option does not.

Kmarquardt at 12:15, 24 July 2009

Kmarquardt — Fri, 24 Jul 2009 12:15:46 GMT

←Older revision		Revision as of 12:15, 24 July 2009
Line 29:		Line 29:
	# The status quo automatically applies if the previous option does not.		# The status quo automatically applies if the previous option does not.

-	~~Do not fall on the dark side~~ of ~~cynicism while trying~~ to overcome ~~the~~ interim solutions ~~you created~~. May you be granted the serenity to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference. [1]	+	You will create many solutions, some of them will be interim, most of them will be useful. The best way to overcome interim solutions is to make them superfluous, to provide a more elegant and useful solution. May you be granted the serenity to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference. [1]

	By [[Klaus Marquardt]]		By [[Klaus Marquardt]]

Kmarquardt at 10:10, 24 July 2009

Kmarquardt — Fri, 24 Jul 2009 10:10:35 GMT

←Older revision		Revision as of 10:10, 24 July 2009
Line 1:		Line 1:
		+	In most systems and teams you will find software that is somewhat dis-integrated from the system, that is considered a draft to be changed sometime, and you will hear developers complaining about these. The drafty, interim solutions that we create have a much longer life than we assumed.
		+
	Why do we create interim solutions?		Why do we create interim solutions?

	Typically there is some immediate problem to solve. It might be internal to the development team, some tooling that fills a gap in the tool chain. It might be external, visible to end users, such as a workaround that addresses missing functionality.		Typically there is some immediate problem to solve. It might be internal to the development team, some tooling that fills a gap in the tool chain. It might be external, visible to end users, such as a workaround that addresses missing functionality.

-	~~The implication of an~~ interim solution ~~is that it~~ is not fully integrated into the production code, or does not follow the standards and guidelines that shaped the rest of the code. The reasons are many and varied, but the key to an interim solution's success is simple: It is useful.	+	An interim solution is not fully integrated into the production code, or does not follow the standards and guidelines that shaped the rest of the code. The reasons are many and varied, but the key to an interim solution's success is simple: It is useful.

	Interim solutions, however, acquire inertia (or momentum, depending on your point of view). Because they are there, ultimately useful and widely accepted, there is no immediate need to do anything else. Whenever a stakeholder has to decide what action adds the most value, there will be many that are ranked higher than proper integration of an interim solution. Why? Because it is there, it works, and it is accepted. The only perceived downside is that it does not follow the chosen standards and guidelines — except for a few niche markets, this is not considered to be a significant force.		Interim solutions, however, acquire inertia (or momentum, depending on your point of view). Because they are there, ultimately useful and widely accepted, there is no immediate need to do anything else. Whenever a stakeholder has to decide what action adds the most value, there will be many that are ranked higher than proper integration of an interim solution. Why? Because it is there, it works, and it is accepted. The only perceived downside is that it does not follow the chosen standards and guidelines — except for a few niche markets, this is not considered to be a significant force.
Line 13:		Line 15:
	Is this a problem?		Is this a problem?

-	The answer depends on your mileage and your stake in the production code standards. However, this is probably the wrong question to ask. Remember that we are talking about a solution. It may not be your preferred solution — it is unlikely to be anybody's preferred solution — but the motivation to rework this solution is too weak.	+	The answer depends on your mileage and your stake in the production code standards. When the systems contains too many interim solutions, its entropy or internal complexity grows and its maintainability decreses. However, this is probably the wrong question to ask first. Remember that we are talking about a solution. It may not be your preferred solution — it is unlikely to be anybody's preferred solution — but the motivation to rework this solution is too weak.

	So what can we do if we see a problem?		So what can we do if we see a problem?

Kmarquardt at 09:14, 23 July 2009

Kmarquardt — Thu, 23 Jul 2009 09:14:09 GMT

←Older revision		Revision as of 09:14, 23 July 2009
Line 9:		Line 9:
	So the interim solution remains in place. Forever.		So the interim solution remains in place. Forever.

-	And if problems arise with that interim solution, it is unlikely there will be provision for an update that brings it into line with acceptable production quality. What to do? A quick interim update on that interim solution often does the job. And will most likely be well received. It exhibits the same strengths as the initial interim solution... ~~but there~~ is ~~now~~ more up to date.	+	And if problems arise with that interim solution, it is unlikely there will be provision for an update that brings it into line with acceptable production quality. What to do? A quick interim update on that interim solution often does the job. And will most likely be well received. It exhibits the same strengths as the initial interim solution... it is just more up to date.

	Is this a problem?		Is this a problem?

-	~~Remember that~~ this is a solution. It may not be your preferred solution — it is unlikely to be anybody's preferred solution — but the motivation to ~~remove~~ this solution is too weak.	+	The answer depends on your mileage and your stake in the production code standards. However, this is probably the wrong question to ask. Remember that we are talking about a solution. It may not be your preferred solution — it is unlikely to be anybody's preferred solution — but the motivation to rework this solution is too weak.

-	~~What~~ can we do?	+	So what can we do if we see a problem?

	# Avoid creating an interim solution in the first place.		# Avoid creating an interim solution in the first place.
Line 23:		Line 23:
	Let's examine these options more closely:		Let's examine these options more closely:

-	# Avoidance does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. Apart from starting a tedious endeavor with ~~possibly no positive~~ outcome, it will only be effective for some future interim solution, not for yours.	+	# Avoidance does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. Apart from starting a tedious endeavor with unclear outcome, it will only be effective for some future interim solution, not for yours.
-	# ~~This kind of change requires that~~ the project culture changes. ~~This can~~ be successful in very small projects — in particular if it's just you — and you just happen do clean the mess without asking in advance. ~~This can~~ also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.	+	# The forces are rooted in the project culture, which resists volitional changes. It could be successful in very small projects — in particular if it's just you — and you just happen to clean the mess without asking in advance. It could also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.
	# The status quo automatically applies if the previous option does not.		# The status quo automatically applies if the previous option does not.

-	Do not fall on the dark side of cynicism while trying to overcome the interim solutions you created. May you be granted the serenity to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference.	+	Do not fall on the dark side of cynicism while trying to overcome the interim solutions you created. May you be granted the serenity to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference. [1]

	By [[Klaus Marquardt]]		By [[Klaus Marquardt]]
Line 37:		Line 37:

	Back to [[97 Things Every Programmer Should Know]] home page		Back to [[97 Things Every Programmer Should Know]] home page
		+
		+	[1] http://en.wikipedia.org/wiki/Serenity_prayer

Kevlin at 11:56, 9 July 2009

Kevlin — Thu, 09 Jul 2009 11:56:15 GMT

Kmarquardt at 14:48, 2 February 2009

Kmarquardt — Mon, 02 Feb 2009 14:48:06 GMT

←Older revision		Revision as of 14:48, 2 February 2009
Line 27:		Line 27:
	# This automatically applies if the previous option does not.		# This automatically applies if the previous option does not.

-	~~Welcome to~~ the ~~cynicism~~ of ~~project veterans~~.	+	Do not fall on the dark side of cynism while trying to overcome the interim solutions you created. May god grant you the serenity to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference.

	By [[Klaus Marquardt]]		By [[Klaus Marquardt]]
		+

	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]		This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Kevlin at 17:15, 31 January 2009

Kevlin — Sat, 31 Jan 2009 17:15:42 GMT

←Older revision		Revision as of 17:15, 31 January 2009
Line 7:		Line 7:
	Interim solutions, however, acquire inertia (or momentum, depending on your point of view). Because they are there, ultimately useful and widely accepted, there is no immediate need to do anything else. Whenever a stakeholder has to decide what action adds the most value, there will be many that are ranked higher than the update of an interim solution. Why? Because it is there, it works, and it is accepted. The only perceived downside is that it does not follow the chosen standards and guidelines — except for a few niche markets, this is not considered to be a significant force.		Interim solutions, however, acquire inertia (or momentum, depending on your point of view). Because they are there, ultimately useful and widely accepted, there is no immediate need to do anything else. Whenever a stakeholder has to decide what action adds the most value, there will be many that are ranked higher than the update of an interim solution. Why? Because it is there, it works, and it is accepted. The only perceived downside is that it does not follow the chosen standards and guidelines — except for a few niche markets, this is not considered to be a significant force.

-	So the interim solution ~~stays~~ in place. Forever.	+	So the interim solution remains in place. Forever.

-	And if problems arise with that interim solution, there will be ~~no plan~~ for an update that ~~follows the standards~~. What to do? A quick interim update on that interim solution often does the job. And ~~no surprise: it~~ will be well received. It exhibits the same strengths as the initial interim solution, but is now more up to date.	+	And if problems arise with that interim solution, it is unlikely there will be provision for an update that brings it into line with acceptable production quality. What to do? A quick interim update on that interim solution often does the job. And will most likely be well received. It exhibits the same strengths as the initial interim solution... but is now more up to date.

	Is this a problem?		Is this a problem?

-	First of all, remember that this is a solution. It may not be your preferred solution — ~~actually nobody might think of~~ it ~~as a~~ preferred solution — but the motivation to remove this solution is too weak.	+	First of all, remember that this is a solution. It may not be your preferred solution — it is unlikely to be anybody's preferred solution — but the motivation to remove this solution is too weak.

	What can we do?		What can we do?

-	# ~~Do not create~~ interim ~~solutions~~ in the first place.	+	# Avoid creating an interim solution in the first place.
	# Change the forces that influence the decision of the project manager.		# Change the forces that influence the decision of the project manager.
	# Leave it as is.		# Leave it as is.
Line 23:		Line 23:
	Let's examine these options more closely:		Let's examine these options more closely:

-	# This does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. Apart from starting a tedious ~~endevour~~ with possibly no positive outcome, it will only be effective for some future interim solution, not for yours.	+	# This does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. Apart from starting a tedious endeavor with possibly no positive outcome, it will only be effective for some future interim solution, not for yours.
	# This requires that the project culture changes. This can be successful in very small projects, in particular if it's just you, and you just happen do clean the mess without asking in advance. This can also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.		# This requires that the project culture changes. This can be successful in very small projects, in particular if it's just you, and you just happen do clean the mess without asking in advance. This can also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.
-	# This automatically applies if B does not.	+	# This automatically applies if the previous option does not.

	Welcome to the cynicism of project veterans.		Welcome to the cynicism of project veterans.
		+
		+	By [[Klaus Marquardt]]
		+
		+	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

Kevlin: The longevity of interim solutions moved to The Longevity of Interim Solutions

Kevlin — Sat, 31 Jan 2009 17:05:41 GMT

The longevity of interim solutions moved to The Longevity of Interim Solutions

←Older revision

Revision as of 17:05, 31 January 2009

Kevlin at 05:56, 28 November 2008

Kevlin — Fri, 28 Nov 2008 05:56:29 GMT

←Older revision		Revision as of 05:56, 28 November 2008
Line 1:		Line 1:
-	Why do ~~you~~ create interim solutions?	+	Why do we create interim solutions?

-	Typically there is some immediate problem to solve. ~~This may~~ be internal to the development team, some tooling that fills a gap in the tool chain. ~~This~~ might be external, visible to end users ~~like some~~ workaround that ~~fixes a~~ missing functionality.	+	Typically there is some immediate problem to solve. It might be internal to the development team, some tooling that fills a gap in the tool chain. It might be external, visible to end users, such as a workaround that addresses missing functionality.

-	The interim solution ~~implies~~ that it is not integrated in the production code, or does not follow the standards ~~in some other way~~. ~~Reasons may be~~ many ~~(maybe we discuss some of that here)~~.	+	The implication of an interim solution is that it is not fully integrated into the production code, or does not follow the standards and guidelines that shaped the rest of the code. The reasons are many and varied, but the key to an interim solution's success is simple: it is useful.

-	~~Now the key factor to the success of the interim solution is: it is useful. This includes functionality as well as accessibility.~~	+	Interim solutions, however, acquire inertia (or momentum, depending on your point of view). Because they are there, ultimately useful and widely accepted, there is no immediate need to do anything else. Whenever a stakeholder has to decide what action adds the most value, there will be many that are ranked higher than the update of an interim solution. Why? Because it is there, it works, and it is accepted. The only perceived downside is that it does not follow the chosen standards and guidelines — except for a few niche markets, this is not considered to be a significant force.
-		+
-	~~No comes the sustaining~~ momentum of ~~interim solutions~~. Because they are there, ultimately useful and widely accepted, there is no immediate need to do ~~something~~ else. Whenever a ~~project manager (or product owner, choose your preferred role definition and vocabulary)~~ has to decide ~~which activity~~ adds the most value, there will be many that are ~~rated~~ higher than the update of ~~that~~ interim solution. Why? Because it is there, it works, and it is accepted. The only downside is that it does not follow the ~~(selected or imposed)~~ standards - and ~~this is hardly an important force,~~ except for a few niche markets.	+

	So the interim solution stays in place. Forever.		So the interim solution stays in place. Forever.

-	And if problems arise with that interim solution, there will be no plan for an update that follows the standards. What to do? ~~Just quickly do an~~ interim update on that interim solution ~~that~~ does the job. ~~Surprise~~: it will be well received. It ~~shows~~ the same strengths ~~that~~ the ~~intial~~ interim solution ~~had~~, ~~plus it works even better~~.	+	And if problems arise with that interim solution, there will be no plan for an update that follows the standards. What to do? A quick interim update on that interim solution often does the job. And no surprise: it will be well received. It exhibits the same strengths as the initial interim solution, but is now more up to date.

	Is this a problem?		Is this a problem?

-	First of all, remember that this is a solution. It may not be your preferred solution, actually nobody might think of it as a preferred ~~soltuion -~~ but the ~~forces that would~~ remove this solution ~~are~~ too weak.	+	First of all, remember that this is a solution. It may not be your preferred solution — actually nobody might think of it as a preferred solution — but the motivation to remove this solution is too weak.
		+
		+	What can we do?

-	~~What could you do?~~	+	# Do not create interim solutions in the first place.
		+	# Change the forces that influence the decision of the project manager.
		+	# Leave it as is.

-	~~a. leave it as is.~~	+	Let's examine these options more closely:
-	~~b. change the forces that influence the decision of the project manager.~~	+
-	~~c. do not create interim solutions in the first place.~~	+

-	~~Let's take a look at these actions.~~	+	# This does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. Apart from starting a tedious endevour with possibly no positive outcome, it will only be effective for some future interim solution, not for yours.
-	~~C -~~ does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy ~~in changing~~ the standards. ~~Besides that you start~~ a tedious endevour with possibly no positive outcome, it will only be effective for some future interim solution, not for yours.	+	# This requires that the project culture changes. This can be successful in very small projects, in particular if it's just you, and you just happen do clean the mess without asking in advance. This can also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.
-	~~B -~~ requires that the project culture changes. This can be successful in very small projects, in particular if it's just you, and you just happen do clean the mess without asking in advance. This can also be successful if the project is such a mess that it is ~~visibilly~~ stalled and some time for cleaning up is commonly accepted.	+	# This automatically applies if B does not.
-	~~A -~~ automatically applies if B does not.	+

-	Welcome to the ~~cynism~~ of project veterans.	+	Welcome to the cynicism of project veterans.

←Older revision		Revision as of 11:56, 9 July 2009
Line 3:		Line 3:
	Typically there is some immediate problem to solve. It might be internal to the development team, some tooling that fills a gap in the tool chain. It might be external, visible to end users, such as a workaround that addresses missing functionality.		Typically there is some immediate problem to solve. It might be internal to the development team, some tooling that fills a gap in the tool chain. It might be external, visible to end users, such as a workaround that addresses missing functionality.

-	The implication of an interim solution is that it is not fully integrated into the production code, or does not follow the standards and guidelines that shaped the rest of the code. The reasons are many and varied, but the key to an interim solution's success is simple: it is useful.	+	The implication of an interim solution is that it is not fully integrated into the production code, or does not follow the standards and guidelines that shaped the rest of the code. The reasons are many and varied, but the key to an interim solution's success is simple: It is useful.

-	Interim solutions, however, acquire inertia (or momentum, depending on your point of view). Because they are there, ultimately useful and widely accepted, there is no immediate need to do anything else. Whenever a stakeholder has to decide what action adds the most value, there will be many that are ranked higher than ~~the update~~ of an interim solution. Why? Because it is there, it works, and it is accepted. The only perceived downside is that it does not follow the chosen standards and guidelines — except for a few niche markets, this is not considered to be a significant force.	+	Interim solutions, however, acquire inertia (or momentum, depending on your point of view). Because they are there, ultimately useful and widely accepted, there is no immediate need to do anything else. Whenever a stakeholder has to decide what action adds the most value, there will be many that are ranked higher than proper integration of an interim solution. Why? Because it is there, it works, and it is accepted. The only perceived downside is that it does not follow the chosen standards and guidelines — except for a few niche markets, this is not considered to be a significant force.

	So the interim solution remains in place. Forever.		So the interim solution remains in place. Forever.

-	And if problems arise with that interim solution, it is unlikely there will be provision for an update that brings it into line with acceptable production quality. What to do? A quick interim update on that interim solution often does the job. And will most likely be well received. It exhibits the same strengths as the initial interim solution... but is now more up to date.	+	And if problems arise with that interim solution, it is unlikely there will be provision for an update that brings it into line with acceptable production quality. What to do? A quick interim update on that interim solution often does the job. And will most likely be well received. It exhibits the same strengths as the initial interim solution... but there is now more up to date.

	Is this a problem?		Is this a problem?

-	~~First of all, remember~~ that this is a solution. It may not be your preferred solution — it is unlikely to be anybody's preferred solution — but the motivation to remove this solution is too weak.	+	Remember that this is a solution. It may not be your preferred solution — it is unlikely to be anybody's preferred solution — but the motivation to remove this solution is too weak.

	What can we do?		What can we do?
Line 23:		Line 23:
	Let's examine these options more closely:		Let's examine these options more closely:

-	# ~~This~~ does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. Apart from starting a tedious endeavor with possibly no positive outcome, it will only be effective for some future interim solution, not for yours.	+	# Avoidance does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. Apart from starting a tedious endeavor with possibly no positive outcome, it will only be effective for some future interim solution, not for yours.
-	# This requires that the project culture changes. This can be successful in very small projects, in particular if it's just you, and you just happen do clean the mess without asking in advance. This can also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.	+	# This kind of change requires that the project culture changes. This can be successful in very small projects — in particular if it's just you — and you just happen do clean the mess without asking in advance. This can also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.
-	# ~~This~~ automatically applies if the previous option does not.	+	# The status quo automatically applies if the previous option does not.

-	Do not fall on the dark side of ~~cynism~~ while trying to overcome the interim solutions you created. May ~~god grant~~ you the serenity to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference.	+	Do not fall on the dark side of cynicism while trying to overcome the interim solutions you created. May you be granted the serenity to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference.

	By [[Klaus Marquardt]]		By [[Klaus Marquardt]]