Reuse Implies Coupling - Revision history

Kevlin at 21:26, 7 August 2009

Kevlin — Fri, 07 Aug 2009 21:26:44 GMT

←Older revision		Revision as of 21:26, 7 August 2009
Line 15:		Line 15:
	Which brings us to the third cause. Dependency means that you are no longer the smith of your own luck. You will be fine as long as the code you reuse is considered a commodity, something you really really don't want to do yourself. Otherwise, you will find good reasons why to not reuse — such as depending on something you don't own, know, maintain, or schedule. Even if you want to reuse some code from elsewhere, the owner or manager of that code might not support your initiative. And providing code for reuse necessitates a more careful design, more deliberate change control, and additional effort to support your users, all of which leaves less time for other duties.		Which brings us to the third cause. Dependency means that you are no longer the smith of your own luck. You will be fine as long as the code you reuse is considered a commodity, something you really really don't want to do yourself. Otherwise, you will find good reasons why to not reuse — such as depending on something you don't own, know, maintain, or schedule. Even if you want to reuse some code from elsewhere, the owner or manager of that code might not support your initiative. And providing code for reuse necessitates a more careful design, more deliberate change control, and additional effort to support your users, all of which leaves less time for other duties.

-	The coupling issues are amplified when you implement reuse across your company. All of a sudden, the provider and all of the reusers are coupled to each other. And worse, even the reusers are indirectly coupled to one another. Each feature or change initiates debates about its relevance and priority, its schedule, and which interfaces will be affected. All the reusing projects struggle with each other and with the provider to have their expectation covered first. Successfully reused software typically brings a tremendous amount of management and overhead as well as the success.	+	The coupling issues are amplified when you implement reuse across your company. All of a sudden, the provider and all of the reusers are coupled to each other. And worse, even the reusers are indirectly coupled to one another. Each feature or change initiates debates about its relevance and priority, its schedule, and which interfaces will be affected. All the reusing projects struggle with each other and with the provider to have their expectation covered first. Successfully reused software typically brings a tremendous amount of management and overhead (as well as the success).

	An alternative approach for coping with reuse is to allow for forking, with deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling at the expense of having less quality for free. After a while this ceases to be reuse. It becomes reuse when, every now and then, all the variants are reintegrated into an evolving baseline that becomes more stable over the months and years. With this mindset of sustainability over accountability, your company might be able to achieve the prerequisite for successful reuse: Software that is considered a commodity.		An alternative approach for coping with reuse is to allow for forking, with deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling at the expense of having less quality for free. After a while this ceases to be reuse. It becomes reuse when, every now and then, all the variants are reintegrated into an evolving baseline that becomes more stable over the months and years. With this mindset of sustainability over accountability, your company might be able to achieve the prerequisite for successful reuse: Software that is considered a commodity.

Kevlin at 06:32, 7 August 2009

Kevlin — Fri, 07 Aug 2009 06:32:52 GMT

←Older revision		Revision as of 06:32, 7 August 2009
Line 1:		Line 1:
-	Most of the Big Topics (~~with a~~ capital ~~b and t~~) in the discussion ~~about~~ software engineering and practices are about improving productivity and avoiding mistakes.	+	Most of the Big Topics (capital ''B'', capital ''T'') in the discussion of software engineering and practices are about improving productivity and avoiding mistakes. Reuse has the potential to address both aspects. It can improve your productivity since you needn't write code that you reuse from elsewhere. And after code has been employed (reused) many times, it can safely be considered tested and proven more thoroughly than your average piece of code.
-	Reuse has the potential to address both aspects. It can improve your productivity since you needn't write code that you reuse from elsewhere. And after code has been employed (reused) many times, it can ~~safety~~ be considered tested and proven more ~~intense~~ than your average piece of code.	+

-	It is no surprise that reuse, and all the debate on how to achieve it, is around for decades. Object oriented programming, components, SOA, parts of open source development, and model driven architecture all include a fair amount of support for reuse, at least in their claims.	+	It is no surprise that reuse, and all the debate on how to achieve it, has been around for decades. Object-oriented programming, components, SOA, parts of open source development, and model-driven architecture all include a fair amount of support for reuse, at least in their claims.

	At the same time, software reuse has hardly lived up to its promises. I think this has multiple causes:		At the same time, software reuse has hardly lived up to its promises. I think this has multiple causes:
-	# it is hard to write reusable code;
-	# it is hard to reuse code;
-	# reuse implies coupling.

-	~~The first topic has~~ to ~~do with interface design, negotiations with many customers, and marketing - and~~ is ~~covered by other aticles here that give sound advice how~~ to ~~design good interfaces~~.	+	# It is hard to write reusable code.
		+	# It is hard to reuse code.
		+	# Reuse implies coupling.

-	The ~~second~~ has ~~two aspects: it is mentally hart to want to reuse, and often technically hard~~ to do ~~so then. It works fine~~ with ~~operating systems~~, libraries, middleware. And we have enjoyed some components from open source projects. However, we often fail to reuse software from our colleagues or from unrelated projects within our company. Not only is it way more sexy to design something yourself, and ~~you are surely way better at design than any of your peers. Reuse would also make you depend on somebody else~~.	+	The first cause has to do with interface design, negotiations with many customers, and marketing.

-	~~This dependency is the first aspect of coupling introduced by~~ reuse. ~~You are not the smith of your own luck any longer. You will be~~ fine ~~as long as the code you reuse is considered a commodity~~, ~~something you really really don't want to do yourself. Otherwise~~, ~~you will find good reasons why this code shouldn't be reused — like that you'd depend on something that you don't own~~, ~~known~~, ~~maintain~~, ~~or schedule. Even if you'd want~~ to reuse ~~some code~~ from ~~elsewhere, the owner~~ or ~~manager of that code might not like your initiative~~. ~~Providing code for reuse includes a~~ more ~~careful~~ design, ~~a more sophisticated change control, and spending effort in supporting the user — all leaving less time for other duties~~.	+	The second has two aspects: It takes mental effort to want to reuse; it takes technical effort to reuse. Reuse works fine with operating systems, libraries, and middleware, whether commercial or open source. We often fail, however, to reuse software from our colleagues or from unrelated projects within our company. Not only is it way more sexy to design something yourself, reuse would also make you depend on somebody else.

-	~~The other facette of coupling comes when~~ you ~~actually implement reuse within~~ your ~~company~~. ~~All of~~ a ~~sudden~~, ~~the provider and all of the reusers are coupled~~ to ~~each other~~. ~~To worsen things~~, ~~even the reusers are coupled with each other~~ — ~~indirectly~~. ~~Each feature~~ or ~~change initiates debates about its relevance and priority~~, ~~when it shall be introduced~~, and which ~~interfaces will be affected. All the reusing projects struggle with each~~ other ~~and with the provider to have their expectation covered first~~.	+	Which brings us to the third cause. Dependency means that you are no longer the smith of your own luck. You will be fine as long as the code you reuse is considered a commodity, something you really really don't want to do yourself. Otherwise, you will find good reasons why to not reuse — such as depending on something you don't own, know, maintain, or schedule. Even if you want to reuse some code from elsewhere, the owner or manager of that code might not support your initiative. And providing code for reuse necessitates a more careful design, more deliberate change control, and additional effort to support your users, all of which leaves less time for other duties.

-	~~Looking at~~ reuse ~~endeavors at different companies~~, ~~these concerns~~ are ~~real~~. Successfully reused software typically brings a tremendous amount of management and overhead.	+	The coupling issues are amplified when you implement reuse across your company. All of a sudden, the provider and all of the reusers are coupled to each other. And worse, even the reusers are indirectly coupled to one another. Each feature or change initiates debates about its relevance and priority, its schedule, and which interfaces will be affected. All the reusing projects struggle with each other and with the provider to have their expectation covered first. Successfully reused software typically brings a tremendous amount of management and overhead as well as the success.

-	~~Alternatively, it requires a contemplative mindset of all involved parties. The other scenario to cope~~ with reuse is to allow for deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling on the ~~expenses~~ of having less quality for free. ~~This is not yet~~ reuse~~, though~~. It becomes reuse when ~~some developer is responible to integrate~~ all variants ~~every once in a while, and to evolve a~~ baseline that becomes more stable over the months and years. With this mindset of sustainability over accountability, your company might be able to achieve the prerequisite for successful reuse: ~~software~~ that is considered a commodity.	+	An alternative approach for coping with reuse is to allow for forking, with deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling at the expense of having less quality for free. After a while this ceases to be reuse. It becomes reuse when, every now and then, all the variants are reintegrated into an evolving baseline that becomes more stable over the months and years. With this mindset of sustainability over accountability, your company might be able to achieve the prerequisite for successful reuse: Software that is considered a commodity.

Kmarquardt at 12:58, 5 August 2009

Kmarquardt — Wed, 05 Aug 2009 12:58:19 GMT

←Older revision		Revision as of 12:58, 5 August 2009
Line 11:		Line 11:
	The first topic has to do with interface design, negotiations with many customers, and marketing - and is covered by other aticles here that give sound advice how to design good interfaces.		The first topic has to do with interface design, negotiations with many customers, and marketing - and is covered by other aticles here that give sound advice how to design good interfaces.

-	The second has two aspects: it is mentally hart to want to reuse, and often technically hard to do so then. It works fine with operating systems, libraries, middleware. And we have enjoyed some components from open source projects. However, we often fail to reuse software from our colleagues or from unrelated projects within our company. Not only is it way more sexy to design something yourself, and you are surely way better at design than any of your peers. It also ~~makes~~ you depend on somebody else.	+	The second has two aspects: it is mentally hart to want to reuse, and often technically hard to do so then. It works fine with operating systems, libraries, middleware. And we have enjoyed some components from open source projects. However, we often fail to reuse software from our colleagues or from unrelated projects within our company. Not only is it way more sexy to design something yourself, and you are surely way better at design than any of your peers. Reuse would also make you depend on somebody else.

-	This dependency is the first aspect of coupling introduced by reuse. You are not the smith of your own luck any longer. You will be fine as long as the code you reuse is considered a commodity, something you really really don't want to do yourself. Otherwise, you will find good reasons why this code shouldn't be reused — like that you'd depend on something that you don't own, known, or maintain. Even if you'd want to reuse some code from elsewhere, the owner or manager of that code might not like your initiative. Providing code for reuse includes a more careful design, a more sophisticated change control, and spending effort in supporting the user — all leaving less time for other duties.	+	This dependency is the first aspect of coupling introduced by reuse. You are not the smith of your own luck any longer. You will be fine as long as the code you reuse is considered a commodity, something you really really don't want to do yourself. Otherwise, you will find good reasons why this code shouldn't be reused — like that you'd depend on something that you don't own, known, maintain, or schedule. Even if you'd want to reuse some code from elsewhere, the owner or manager of that code might not like your initiative. Providing code for reuse includes a more careful design, a more sophisticated change control, and spending effort in supporting the user — all leaving less time for other duties.

-	The other facette of coupling comes when you actually implement reuse within your company. All of a sudden, the provider and all of the reusers are coupled to each other. Each feature or change initiates debates about its relevance and priority, when it shall be introduced, and which interfaces will be affected. All the reusing projects struggle with each other and with the provider to have their expectation covered first.	+	The other facette of coupling comes when you actually implement reuse within your company. All of a sudden, the provider and all of the reusers are coupled to each other. To worsen things, even the reusers are coupled with each other — indirectly. Each feature or change initiates debates about its relevance and priority, when it shall be introduced, and which interfaces will be affected. All the reusing projects struggle with each other and with the provider to have their expectation covered first.

	Looking at reuse endeavors at different companies, these concerns are real. Successfully reused software typically brings a tremendous amount of management and overhead.		Looking at reuse endeavors at different companies, these concerns are real. Successfully reused software typically brings a tremendous amount of management and overhead.

Kmarquardt at 10:31, 24 July 2009

Kmarquardt — Fri, 24 Jul 2009 10:31:07 GMT

←Older revision		Revision as of 10:31, 24 July 2009
Line 1:		Line 1:
-	Most of the Big Topics (with a capital b and t) in the discussion about software engineering and practices are about improving productivity, and avoiding mistakes.	+	Most of the Big Topics (with a capital b and t) in the discussion about software engineering and practices are about improving productivity and avoiding mistakes.
-	Reuse has the potential to address both ~~dimensions~~. It can improve your productivity since you needn't write ~~that~~ code ~~yourself~~ that you reuse from elsewhere. And after code has been employed (reused) many times, it can safety be considered tested and proven more than your average piece of code.	+	Reuse has the potential to address both aspects. It can improve your productivity since you needn't write code that you reuse from elsewhere. And after code has been employed (reused) many times, it can safety be considered tested and proven more intense than your average piece of code.

-	No surprise that reuse, and all the debate on how to achieve it, is around for decades. Object oriented programming ~~was about reuse~~, ~~component ware~~, parts of open source development, and model driven architecture ~~with~~ all ~~possibilities~~ for ~~variation~~.	+	It is no surprise that reuse, and all the debate on how to achieve it, is around for decades. Object oriented programming, components, SOA, parts of open source development, and model driven architecture all include a fair amount of support for reuse, at least in their claims.

	At the same time, software reuse has hardly lived up to its promises. I think this has multiple causes:		At the same time, software reuse has hardly lived up to its promises. I think this has multiple causes:
Line 11:		Line 11:
	The first topic has to do with interface design, negotiations with many customers, and marketing - and is covered by other aticles here that give sound advice how to design good interfaces.		The first topic has to do with interface design, negotiations with many customers, and marketing - and is covered by other aticles here that give sound advice how to design good interfaces.

-	The second has two aspects: it is mentally hart to want to reuse, and often technically hard to do so then. It works fine with operating systems, libraries, middleware. And we have enjoyed some components from ~~the~~ open source projects. However, we often fail to reuse software from our colleagues or from unrelated projects within our company. Not only is it way more sexy to design something yourself, and you are surely way better at design than any of your peers. It also makes you depend on somebody else.	+	The second has two aspects: it is mentally hart to want to reuse, and often technically hard to do so then. It works fine with operating systems, libraries, middleware. And we have enjoyed some components from open source projects. However, we often fail to reuse software from our colleagues or from unrelated projects within our company. Not only is it way more sexy to design something yourself, and you are surely way better at design than any of your peers. It also makes you depend on somebody else.

-	This dependency is the first aspect of coupling introduced by reuse. You are not the smith of your own luck any longer. You will be fine as long as the code you reuse is considered a commodity, something you really really don't want to do yourself. Otherwise, you will find good reasons why this code shouldn't be reused~~, including~~ that you depend on something that you don't own ~~and can't~~ maintain, ~~and~~ that is not ~~reliably maintained by somebody else~~. ~~Your peers project manager will hardly agree to~~ spending ~~additional~~ effort in supporting ~~an unrelated team. Yes, most companies work this way~~.	+	This dependency is the first aspect of coupling introduced by reuse. You are not the smith of your own luck any longer. You will be fine as long as the code you reuse is considered a commodity, something you really really don't want to do yourself. Otherwise, you will find good reasons why this code shouldn't be reused — like that you'd depend on something that you don't own, known, or maintain. Even if you'd want to reuse some code from elsewhere, the owner or manager of that code might not like your initiative. Providing code for reuse includes a more careful design, a more sophisticated change control, and spending effort in supporting the user — all leaving less time for other duties.

-	The other facette of coupling comes when you actually implement reuse within your company. All of a sudden, the provider and all of the reusers are coupled to each other. Each feature or change ~~needs~~ debates about its relevance and priority, when it shall be introduced, and which interfaces will be affected. All the ~~reuser project~~ struggle with each other and with the provider to have their expectation covered first.	+	The other facette of coupling comes when you actually implement reuse within your company. All of a sudden, the provider and all of the reusers are coupled to each other. Each feature or change initiates debates about its relevance and priority, when it shall be introduced, and which interfaces will be affected. All the reusing projects struggle with each other and with the provider to have their expectation covered first.

-	Looking at reuse endeavors at different ~~cmpanies~~, these concerns are real. Successfully reused software typically brings a tremendous amount of management and overhead.	+	Looking at reuse endeavors at different companies, these concerns are real. Successfully reused software typically brings a tremendous amount of management and overhead.

	Alternatively, it requires a contemplative mindset of all involved parties. The other scenario to cope with reuse is to allow for deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling on the expenses of having less quality for free. This is not yet reuse, though. It becomes reuse when some developer is responible to integrate all variants every once in a while, and to evolve a baseline that becomes more stable over the months and years. With this mindset of sustainability over accountability, your company might be able to achieve the prerequisite for successful reuse: software that is considered a commodity.		Alternatively, it requires a contemplative mindset of all involved parties. The other scenario to cope with reuse is to allow for deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling on the expenses of having less quality for free. This is not yet reuse, though. It becomes reuse when some developer is responible to integrate all variants every once in a while, and to evolve a baseline that becomes more stable over the months and years. With this mindset of sustainability over accountability, your company might be able to achieve the prerequisite for successful reuse: software that is considered a commodity.
		+
		+
		+	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

Kmarquardt at 15:53, 11 February 2009

Kmarquardt — Wed, 11 Feb 2009 15:53:21 GMT

←Older revision		Revision as of 15:53, 11 February 2009
Line 20:		Line 20:

	Alternatively, it requires a contemplative mindset of all involved parties. The other scenario to cope with reuse is to allow for deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling on the expenses of having less quality for free. This is not yet reuse, though. It becomes reuse when some developer is responible to integrate all variants every once in a while, and to evolve a baseline that becomes more stable over the months and years. With this mindset of sustainability over accountability, your company might be able to achieve the prerequisite for successful reuse: software that is considered a commodity.		Alternatively, it requires a contemplative mindset of all involved parties. The other scenario to cope with reuse is to allow for deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling on the expenses of having less quality for free. This is not yet reuse, though. It becomes reuse when some developer is responible to integrate all variants every once in a while, and to evolve a baseline that becomes more stable over the months and years. With this mindset of sustainability over accountability, your company might be able to achieve the prerequisite for successful reuse: software that is considered a commodity.
-
-
-
-	BACKUP - to be deleted sometime...
-
-
-	There are many items that we just reuse, and have reused for decades without much thought: operating systems, libraries, middleware. And we have enjoyed some components from the open source projects. So, did we create our own software, reusable among our own projects? We did, but with limited success. Here is some of the reason:
-
-	# reuse requires a first user. Attempts to create a library for common use, without having a real need in some real project that spends real time and money, remaing pointless.
-	# reuse requires a second user. Once used, most of the code is not reused in a different project.
-
-	Resaons against reuse:
-	# not invented here
-	# crappy quality: interfaces
-	# crappy quality: dependencies
-	# crappy quality: performance (in the 2nd users scenarios)
-
-
-	Even if you have overcoem all this, and started to develop reusable components in-house. You will find that sooner or later you have three different parties. (1) the creators and maintainers of the reused component; (2) the projects that already use the component; (3) the projects that are about to reuse that component.
-
-	The different groups have strongly opposing desires. Completed projects strive to avoid any changes to the once published component, since each change introduces some risk and some work. Starting projects strive to adapt the component also to their needs, i.e. they long for changes. Unless you have reached a very stable state (see ->library), you will have some debate here. Not just about interfaces and technology. You'll be surprised to find that now different projects are influencing the same code base, and people, and their schedules suddenly are coupled since some action for one of them causes work in the other one.
-
-
-
-
-
-	Do not make your code depend on some file that is intended to change as the project progresses.
-
-	It is very convenient to have a global file that lists all error codes in the system. When starting the new component, you proudly add a handful: look, I am a part of this! Only to find your colleagues moan about the extra build time. How dare you change this file?
-
-	Couldn't you just do what everybody does:
-	* reuse some error codes that are already in there.
-	* when existing codes don't match the intended meaning, document their specific meaning in your component documentation.
-
-	The <code>error.h</code> file was intended to provide a great place to look for the meaning of codes. At the same time, it is a central component that is intended to change as the project proceeds. So it is your base, but it is quicksand.
-
-	How to get out? Consider this:
-	* real generic error messages (in the style of STL exceptions)
-	* a distinct <code>error.h</code> file per component

Kmarquardt at 21:07, 8 February 2009

Kmarquardt — Sun, 08 Feb 2009 21:07:23 GMT

←Older revision		Revision as of 21:07, 8 February 2009
Line 2:		Line 2:
	Reuse has the potential to address both dimensions. It can improve your productivity since you needn't write that code yourself that you reuse from elsewhere. And after code has been employed (reused) many times, it can safety be considered tested and proven more than your average piece of code.		Reuse has the potential to address both dimensions. It can improve your productivity since you needn't write that code yourself that you reuse from elsewhere. And after code has been employed (reused) many times, it can safety be considered tested and proven more than your average piece of code.

-	No surprise that reuse, and all the debate on how to achieve it, is around for decades. Object oriented programming was about reuse, component ware, parts of open source development, and model driven architecture with all possibilities for variation. At the same time, software reuse has hardly lived up to its promises.	+	No surprise that reuse, and all the debate on how to achieve it, is around for decades. Object oriented programming was about reuse, component ware, parts of open source development, and model driven architecture with all possibilities for variation.
		+
		+	At the same time, software reuse has hardly lived up to its promises. I think this has multiple causes:
		+	# it is hard to write reusable code;
		+	# it is hard to reuse code;
		+	# reuse implies coupling.
		+
		+	The first topic has to do with interface design, negotiations with many customers, and marketing - and is covered by other aticles here that give sound advice how to design good interfaces.
		+
		+	The second has two aspects: it is mentally hart to want to reuse, and often technically hard to do so then. It works fine with operating systems, libraries, middleware. And we have enjoyed some components from the open source projects. However, we often fail to reuse software from our colleagues or from unrelated projects within our company. Not only is it way more sexy to design something yourself, and you are surely way better at design than any of your peers. It also makes you depend on somebody else.
		+
		+	This dependency is the first aspect of coupling introduced by reuse. You are not the smith of your own luck any longer. You will be fine as long as the code you reuse is considered a commodity, something you really really don't want to do yourself. Otherwise, you will find good reasons why this code shouldn't be reused, including that you depend on something that you don't own and can't maintain, and that is not reliably maintained by somebody else. Your peers project manager will hardly agree to spending additional effort in supporting an unrelated team. Yes, most companies work this way.
		+
		+	The other facette of coupling comes when you actually implement reuse within your company. All of a sudden, the provider and all of the reusers are coupled to each other. Each feature or change needs debates about its relevance and priority, when it shall be introduced, and which interfaces will be affected. All the reuser project struggle with each other and with the provider to have their expectation covered first.
		+
		+	Looking at reuse endeavors at different cmpanies, these concerns are real. Successfully reused software typically brings a tremendous amount of management and overhead.
		+
		+	Alternatively, it requires a contemplative mindset of all involved parties. The other scenario to cope with reuse is to allow for deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling on the expenses of having less quality for free. This is not yet reuse, though. It becomes reuse when some developer is responible to integrate all variants every once in a while, and to evolve a baseline that becomes more stable over the months and years. With this mindset of sustainability over accountability, your company might be able to achieve the prerequisite for successful reuse: software that is considered a commodity.
		+
		+
		+
		+	BACKUP - to be deleted sometime...
		+

	There are many items that we just reuse, and have reused for decades without much thought: operating systems, libraries, middleware. And we have enjoyed some components from the open source projects. So, did we create our own software, reusable among our own projects? We did, but with limited success. Here is some of the reason:		There are many items that we just reuse, and have reused for decades without much thought: operating systems, libraries, middleware. And we have enjoyed some components from the open source projects. So, did we create our own software, reusable among our own projects? We did, but with limited success. Here is some of the reason:

Kmarquardt at 15:53, 2 February 2009

Kmarquardt — Mon, 02 Feb 2009 15:53:31 GMT

←Older revision		Revision as of 15:53, 2 February 2009
Line 1:		Line 1:
		+	Most of the Big Topics (with a capital b and t) in the discussion about software engineering and practices are about improving productivity, and avoiding mistakes.
		+	Reuse has the potential to address both dimensions. It can improve your productivity since you needn't write that code yourself that you reuse from elsewhere. And after code has been employed (reused) many times, it can safety be considered tested and proven more than your average piece of code.
		+
		+	No surprise that reuse, and all the debate on how to achieve it, is around for decades. Object oriented programming was about reuse, component ware, parts of open source development, and model driven architecture with all possibilities for variation. At the same time, software reuse has hardly lived up to its promises.
		+
		+	There are many items that we just reuse, and have reused for decades without much thought: operating systems, libraries, middleware. And we have enjoyed some components from the open source projects. So, did we create our own software, reusable among our own projects? We did, but with limited success. Here is some of the reason:
		+
		+	# reuse requires a first user. Attempts to create a library for common use, without having a real need in some real project that spends real time and money, remaing pointless.
		+	# reuse requires a second user. Once used, most of the code is not reused in a different project.
		+
		+	Resaons against reuse:
		+	# not invented here
		+	# crappy quality: interfaces
		+	# crappy quality: dependencies
		+	# crappy quality: performance (in the 2nd users scenarios)
		+
		+
		+	Even if you have overcoem all this, and started to develop reusable components in-house. You will find that sooner or later you have three different parties. (1) the creators and maintainers of the reused component; (2) the projects that already use the component; (3) the projects that are about to reuse that component.
		+
		+	The different groups have strongly opposing desires. Completed projects strive to avoid any changes to the once published component, since each change introduces some risk and some work. Starting projects strive to adapt the component also to their needs, i.e. they long for changes. Unless you have reached a very stable state (see ->library), you will have some debate here. Not just about interfaces and technology. You'll be surprised to find that now different projects are influencing the same code base, and people, and their schedules suddenly are coupled since some action for one of them causes work in the other one.
		+
		+
		+
		+
		+
	Do not make your code depend on some file that is intended to change as the project progresses.		Do not make your code depend on some file that is intended to change as the project progresses.

Kevlin at 16:27, 31 January 2009

Kevlin — Sat, 31 Jan 2009 16:27:31 GMT

←Older revision		Revision as of 16:27, 31 January 2009
Line 1:		Line 1:
-
-	Renaming intended: Reuse implies Coupling.
-
-
-
	Do not make your code depend on some file that is intended to change as the project progresses.		Do not make your code depend on some file that is intended to change as the project progresses.

Kevlin: Quicksand Base moved to Reuse Implies Coupling

Kevlin — Sat, 31 Jan 2009 16:27:13 GMT

Quicksand Base moved to Reuse Implies Coupling

←Older revision

Revision as of 16:27, 31 January 2009

Kmarquardt at 16:37, 23 January 2009

Kmarquardt — Fri, 23 Jan 2009 16:37:13 GMT

←Older revision		Revision as of 16:37, 23 January 2009
Line 1:		Line 1:
		+
		+	Renaming intended: Reuse implies Coupling.
		+
		+
		+
	Do not make your code depend on some file that is intended to change as the project progresses.		Do not make your code depend on some file that is intended to change as the project progresses.