Contribution 30 - Revision history

Rmonson at 17:27, 13 July 2008

2008-07-13T17:27:28Z

←Older revision		Revision as of 17:27, 13 July 2008
Line 19:		Line 19:
	Understanding how to reuse an element depends on skills and training. Of course there are those people who (to use Donald Knuth’s terminology) "resonate" with coding and design. We have all worked with them, the gifted developers and architects whose speed and depth of understanding is impressive, even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught.		Understanding how to reuse an element depends on skills and training. Of course there are those people who (to use Donald Knuth’s terminology) "resonate" with coding and design. We have all worked with them, the gifted developers and architects whose speed and depth of understanding is impressive, even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught.

-	Developers and designers might not know of the particular design pattern used in a design, or fully understand the inheritance model that the framework designer intended them to use. They need to be given easy access to that information in the form of up-to-date documentation, or even better, training. A little training goes a long way to ensuring that everyone is on the same page when it comes to reuse. Don’t depend on people to ask for training or to train themselves, for to many people the pre-requisite of structured learning can be seen as an impediment to productivity. Make sure you have a clear route to information. A learning path which is easily accessible and attractive will encourage people to learn more about elements of an architecture. Obscure information or complicated training requirements will encourage them to try and solve the problem some other way.	+	Developers and designers might not know of the particular design pattern used in a design, or fully understand the inheritance model that the framework designer intended them to use. They need to be given easy access to that information in the form of up-to-date documentation, or even better, training. A little training goes a long way to ensuring that everyone is on the same page when it comes to reuse.

	'''c) Are convinced that its better than doing it themselves'''		'''c) Are convinced that its better than doing it themselves'''

Rmonson at 17:23, 13 July 2008

2008-07-13T17:23:44Z

←Older revision		Revision as of 17:23, 13 July 2008
Line 13:		Line 13:
	Within your organization, developers or designers need to know a design, framework, library, or fragments of code exists and where they can find all the critical information about these elements (e.g. documentation, versions, and compatibility) in order to reuse them. It is a simple, logical truth that people won't look for things that they don't believe to exist. You are more likely to succeed with reusable elements if the information about them is “pushed”.		Within your organization, developers or designers need to know a design, framework, library, or fragments of code exists and where they can find all the critical information about these elements (e.g. documentation, versions, and compatibility) in order to reuse them. It is a simple, logical truth that people won't look for things that they don't believe to exist. You are more likely to succeed with reusable elements if the information about them is “pushed”.

-	There are any number of methods pushing information about reusable elements in an organization. These range from wiki pages with an RSS feed providing update information, useful in very large teams, to e-mail announcing version updates in the source repository. In a tiny team, the designer or lead developer can inform his colleagues in personal conversations or shouting it across the office. Ultimately, whatever your process for communicating about reusable elements... make sure you have one, don’t leave it up to chance.	+	There are any number of methods for pushing information about reusable elements in an organization. These range from wiki pages with an RSS feed providing update information, useful in very large teams, to e-mail announcing version updates in the source repository. In a tiny team, the designer or lead developer can inform his colleagues in personal conversations or shouting it across the office. Ultimately, whatever your process for communicating about reusable elements... make sure you have one, don’t leave it up to chance.

	'''b) Know how to use it'''		'''b) Know how to use it'''
Line 19:		Line 19:
	Understanding how to reuse an element depends on skills and training. Of course there are those people who (to use Donald Knuth’s terminology) "resonate" with coding and design. We have all worked with them, the gifted developers and architects whose speed and depth of understanding is impressive, even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught.		Understanding how to reuse an element depends on skills and training. Of course there are those people who (to use Donald Knuth’s terminology) "resonate" with coding and design. We have all worked with them, the gifted developers and architects whose speed and depth of understanding is impressive, even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught.

-	Developers and designers might not know of the particular design pattern used in a design, or fully understand the inheritance model that the framework designer intended them to use. They need to be given easy access to that information in the form of up to date documentation, or even better, training. A little training goes a long way to ensuring that everyone is on the same page when it comes to reuse. Don’t depend on people to ask for training or to train themselves, to many people the pre-requisite of structured learning can be seen as an impediment to ~~quickly reaching their target of producing something that works~~. Make sure you have or a clear route to information ~~and competency with your reusable elements~~. A learning path which is easily accessible and attractive will encourage people to learn more about elements of an architecture. Obscure information or complicated training ~~recommendations,~~ will encourage them to try and solve the problem some other way.	+	Developers and designers might not know of the particular design pattern used in a design, or fully understand the inheritance model that the framework designer intended them to use. They need to be given easy access to that information in the form of up-to-date documentation, or even better, training. A little training goes a long way to ensuring that everyone is on the same page when it comes to reuse. Don’t depend on people to ask for training or to train themselves, for to many people the pre-requisite of structured learning can be seen as an impediment to productivity. Make sure you have a clear route to information. A learning path which is easily accessible and attractive will encourage people to learn more about elements of an architecture. Obscure information or complicated training requirements will encourage them to try and solve the problem some other way.

	'''c) Are convinced that its better than doing it themselves'''		'''c) Are convinced that its better than doing it themselves'''

-	People, and particularly developers, ~~will~~ tend to prefer to solve problems themselves rather than ask. Asking how something works is a sign of weakness, or even an indication of ignorance~~, so if there is a way of getting the library to compile, or “hacking” a result out of a framework, your average software creator will do that~~.	+	People, and particularly developers, tend to prefer to solve problems themselves rather than ask for help. Asking how something works is a sign of weakness, or even an indication of ignorance. This has a lot to do with the maturity and personality type of your individual team-members, “Better than doing it themselves” means different things to different people. The “young guns” on your team will always want to write things themselves because it appeases their ego, whereas your more experienced people are more likely to accept that someone else has given thought to the problem domain and has something to offer in terms of a solution.
-		+
-	This has a lot to do with the maturity and personality type of your individual team-members, “Better than doing it themselves” means different things to different people. The “young guns” on your team will always want to write things themselves because it appeases their ego, whereas your more experienced people are more likely to accept that someone else has given thought to the problem domain and has something to offer in terms of a solution.	+
-		+
-	~~If your team is doesn’t know where to find reusable artifacts or how to reuse them they will default to the natural, human position: they will build it themselves. And you will pay for it~~.	+

		+	If your team doesn’t know where to find reusable artifacts or how to reuse them they will default to the natural, human position: they will build it themselves. And you will pay for it.

		+	(RMH Edited 7/13/2008)

	By [[Jeremy Meyer]]		By [[Jeremy Meyer]]

Rmonson at 12:42, 28 May 2008

2008-05-28T12:42:21Z

←Older revision		Revision as of 12:42, 28 May 2008
Line 4:		Line 4:

	a) know it is there		a) know it is there
		+
	b) know how to use it		b) know how to use it
		+
	c) are convinced that it is better than doing it themselves		c) are convinced that it is better than doing it themselves

-	a) Know its there	+	'''a) Know its there'''
		+
	Within your organization, developers or designers need to know a design, framework, library, or fragments of code exists and where they can find all the critical information about these elements (e.g. documentation, versions, and compatibility) in order to reuse them. It is a simple, logical truth that people won't look for things that they don't believe to exist. You are more likely to succeed with reusable elements if the information about them is “pushed”.		Within your organization, developers or designers need to know a design, framework, library, or fragments of code exists and where they can find all the critical information about these elements (e.g. documentation, versions, and compatibility) in order to reuse them. It is a simple, logical truth that people won't look for things that they don't believe to exist. You are more likely to succeed with reusable elements if the information about them is “pushed”.

	There are any number of methods pushing information about reusable elements in an organization. These range from wiki pages with an RSS feed providing update information, useful in very large teams, to e-mail announcing version updates in the source repository. In a tiny team, the designer or lead developer can inform his colleagues in personal conversations or shouting it across the office. Ultimately, whatever your process for communicating about reusable elements... make sure you have one, don’t leave it up to chance.		There are any number of methods pushing information about reusable elements in an organization. These range from wiki pages with an RSS feed providing update information, useful in very large teams, to e-mail announcing version updates in the source repository. In a tiny team, the designer or lead developer can inform his colleagues in personal conversations or shouting it across the office. Ultimately, whatever your process for communicating about reusable elements... make sure you have one, don’t leave it up to chance.

-	b) Know how to use it	+	'''b) Know how to use it'''
		+
	Understanding how to reuse an element depends on skills and training. Of course there are those people who (to use Donald Knuth’s terminology) "resonate" with coding and design. We have all worked with them, the gifted developers and architects whose speed and depth of understanding is impressive, even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught.		Understanding how to reuse an element depends on skills and training. Of course there are those people who (to use Donald Knuth’s terminology) "resonate" with coding and design. We have all worked with them, the gifted developers and architects whose speed and depth of understanding is impressive, even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught.
-

	Developers and designers might not know of the particular design pattern used in a design, or fully understand the inheritance model that the framework designer intended them to use. They need to be given easy access to that information in the form of up to date documentation, or even better, training. A little training goes a long way to ensuring that everyone is on the same page when it comes to reuse. Don’t depend on people to ask for training or to train themselves, to many people the pre-requisite of structured learning can be seen as an impediment to quickly reaching their target of producing something that works. Make sure you have or a clear route to information and competency with your reusable elements. A learning path which is easily accessible and attractive will encourage people to learn more about elements of an architecture. Obscure information or complicated training recommendations, will encourage them to try and solve the problem some other way.		Developers and designers might not know of the particular design pattern used in a design, or fully understand the inheritance model that the framework designer intended them to use. They need to be given easy access to that information in the form of up to date documentation, or even better, training. A little training goes a long way to ensuring that everyone is on the same page when it comes to reuse. Don’t depend on people to ask for training or to train themselves, to many people the pre-requisite of structured learning can be seen as an impediment to quickly reaching their target of producing something that works. Make sure you have or a clear route to information and competency with your reusable elements. A learning path which is easily accessible and attractive will encourage people to learn more about elements of an architecture. Obscure information or complicated training recommendations, will encourage them to try and solve the problem some other way.

-	c) Are convinced that its better than doing it themselves	+	'''c) Are convinced that its better than doing it themselves'''
		+
	People, and particularly developers, will tend to prefer to solve problems themselves rather than ask. Asking how something works is a sign of weakness, or even an indication of ignorance, so if there is a way of getting the library to compile, or “hacking” a result out of a framework, your average software creator will do that.		People, and particularly developers, will tend to prefer to solve problems themselves rather than ask. Asking how something works is a sign of weakness, or even an indication of ignorance, so if there is a way of getting the library to compile, or “hacking” a result out of a framework, your average software creator will do that.

Rmonson at 12:37, 28 May 2008

2008-05-28T12:37:45Z

←Older revision		Revision as of 12:37, 28 May 2008
Line 1:		Line 1:
	== Reuse is about people and education, not just architecture ==		== Reuse is about people and education, not just architecture ==

-	~~[First draft~~, ~~work in progress currently over 700 words long!!]~~	+	You might adopt the approach that a framework that is well designed, or an architecture that is carefully considered, and cleverly implemented will lend itself to re-use within your organization. The truth is that even the most beautiful, elegant and re-usable architecture, framework or system will only be re-used by people who:

-	~~You might adopt the approach that~~ a ~~framework which well designed, or an architecture which~~ is ~~carefully considered, and cleverly implemented will lend itself~~ to ~~re-~~use ~~of design and functionality within your organisation. You might assume~~ that rich use of design patterns will encourage developers to extend frameworks in the intended way, or that an SOA might create the right environment for producing design solutions rich in the reuse of existing components and functionality.	+	a) know it is there
		+	b) know how to use it
		+	c) are convinced that it is better than doing it themselves

-	~~The truth is that even the most beautiful~~, ~~elegant and re-usable architecture~~, framework or ~~system will only be re-used by~~ people ~~who:~~	+	a) Know its there
		+	Within your organization, developers or designers need to know a design, framework, library, or fragments of code exists and where they can find all the critical information about these elements (e.g. documentation, versions, and compatibility) in order to reuse them. It is a simple, logical truth that people won't look for things that they don't believe to exist. You are more likely to succeed with reusable elements if the information about them is “pushed”.

-	a~~) know~~ it ~~is there<br>~~	+	There are any number of methods pushing information about reusable elements in an organization. These range from wiki pages with an RSS feed providing update information, useful in very large teams, to e-mail announcing version updates in the source repository. In a tiny team, the designer or lead developer can inform his colleagues in personal conversations or shouting it across the office. Ultimately, whatever your process for communicating about reusable elements... make sure you have one, don’t leave it up to chance.
-	~~b) know how~~ to ~~use it<br>~~	+
-	~~c) are convinced that it is better than doing it themselves <br><br>~~	+

-	~~A ] should be simple. Within your organisation, whether your developers or designers should be reusing a design, a framework or a library, or even just fragments of code, they need~~ to ~~know that~~ it is there, and ~~where they can find~~ all the ~~critical information about it (like version~~ and ~~compatibility). It~~ is ~~a simple~~, ~~logical truth that~~ people ~~won't look for things that they don't believe to exist~~, and ~~it isn't in peoples' nature to give the benefit of the doubt to a "solution" that doesn't seem to promise to do the job~~. ~~You are more likely~~ to ~~succeed with reusable elements if the information about them is “pushed”~~.	+	b) Know how to use it
		+	Understanding how to reuse an element depends on skills and training. Of course there are those people who (to use Donald Knuth’s terminology) "resonate" with coding and design. We have all worked with them, the gifted developers and architects whose speed and depth of understanding is impressive, even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught.

-	There are any number of methods getting this right in an organisation. These range from wiki pages with an RSS feed providing update information, useful in very large teams, to e-mail announcing version updates in the source repository. In a tiny team, the designer or lead developer might telling his colleagues personally, or shouting it across the office might be enough.. Ultimately, whatever your process for communicating about reusable elements... make sure you have one, don’t leave it up to chance.
-
-	B] Depends on skills and training. Of course are always those people who (to use Donald Knuth’s terminology) "resonate" with coding and design. We have all worked with them, the gifted developers and architects whose speed and depth of understanding is impressive, even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught.

		+	Developers and designers might not know of the particular design pattern used in a design, or fully understand the inheritance model that the framework designer intended them to use. They need to be given easy access to that information in the form of up to date documentation, or even better, training. A little training goes a long way to ensuring that everyone is on the same page when it comes to reuse. Don’t depend on people to ask for training or to train themselves, to many people the pre-requisite of structured learning can be seen as an impediment to quickly reaching their target of producing something that works. Make sure you have or a clear route to information and competency with your reusable elements. A learning path which is easily accessible and attractive will encourage people to learn more about elements of an architecture. Obscure information or complicated training recommendations, will encourage them to try and solve the problem some other way.
		+
		+	c) Are convinced that its better than doing it themselves
	People, and particularly developers, will tend to prefer to solve problems themselves rather than ask. Asking how something works is a sign of weakness, or even an indication of ignorance, so if there is a way of getting the library to compile, or “hacking” a result out of a framework, your average software creator will do that.		People, and particularly developers, will tend to prefer to solve problems themselves rather than ask. Asking how something works is a sign of weakness, or even an indication of ignorance, so if there is a way of getting the library to compile, or “hacking” a result out of a framework, your average software creator will do that.

-	~~They might not know of the particular design pattern used in~~ a ~~design, or fully understand the inheritance model that the framework designer intended them~~ to ~~use. They need to be given easy access to that information in~~ the ~~form~~ of ~~up to date documentation~~, ~~or even better, training. A little training goes an enormous way to ensuring that everyone is on the same page when~~ it ~~comes~~ to ~~re-use~~. ~~Don’t depend~~ on ~~people~~ to ~~ask for training or train~~ themselves, ~~to many~~ people ~~the pre-requisite of structured learning can be seen as an impediment~~ to ~~quickly reaching their target of producing something~~ that ~~works. Make sure you have or a clear route~~ to ~~information~~ and ~~competency with your reusable elements. A learning path which is easily accessible and attractive will encourage people~~ to ~~gen themselves up. Obscure information or complicated training recommendations, will encourage them to try and solve the problem some other way~~.	+	This has a lot to do with the maturity and personality type of your individual team-members, “Better than doing it themselves” means different things to different people. The “young guns” on your team will always want to write things themselves because it appeases their ego, whereas your more experienced people are more likely to accept that someone else has given thought to the problem domain and has something to offer in terms of a solution.

-	~~C] has a lot~~ to ~~do with~~ the ~~maturity and personality type of your individual team-members~~, ~~“Better than doing~~ it ~~themselves” means different things to different people~~. ~~The “young guns” on your~~ will ~~always want to write things themselves because~~ it ~~appeases their ego, whereas your more experienced people might be more likely to accept someone else has given thought to the problem domain and might just have something to offer with the solution~~.	+	If your team is doesn’t know where to find reusable artifacts or how to reuse them they will default to the natural, human position: they will build it themselves. And you will pay for it.

-	It also has a lot to do with taking care of A] and B], though. Informed and skilled developers will more happily take the smart, lazy approach of reusing something that they perceive will get them to a solution faster. A “young gun” with new found skills in your particular framework, or newly armed with knowledge about your service layer will believe he can produce a good fast solution (perhaps better and faster than everyone else). The mature developer will be equipped with everything he or she needs to do the right thing in the shortest time. If your team are not equipped with the information they need, of if the information they have doesn’t immediately suggest to them that the existing framework, library or architecture will do the job, they will default to the natural, human position. If they don’t perceive that there is anything to reuse or that what is available will help, then they will build it themselves.
-
-	And you will pay for it.


	By [[Jeremy Meyer]]		By [[Jeremy Meyer]]
		+	(Edited RMH 5/28/2008)
		+
		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+
		+	Back to [[97 Things Every Software Architect Should Know]] home page

Jeremyanywhere: Reuse of designs, frameworks and components is on of the key drivers of architecture, but ultimately, people are the issue.

2008-05-18T19:38:53Z

Reuse of designs, frameworks and components is on of the key drivers of architecture, but ultimately, people are the issue.

New page

== Reuse is about people and education, not just architecture ==

[First draft, work in progress currently over 700 words long!!]

You might adopt the approach that a framework which well designed, or an architecture which is carefully considered, and cleverly implemented will lend itself to re-use of design and functionality within your organisation. You might assume that rich use of design patterns will encourage developers to extend frameworks in the intended way, or that an SOA might create the right environment for producing design solutions rich in the reuse of existing components and functionality.

The truth is that even the most beautiful, elegant and re-usable architecture, framework or system will only be re-used by people who:

a) know it is there<br>
b) know how to use it<br>
c) are convinced that it is better than doing it themselves <br><br>

A ] should be simple. Within your organisation, whether your developers or designers should be reusing a design, a framework or a library, or even just fragments of code, they need to know that it is there, and where they can find all the critical information about it (like version and compatibility). It is a simple, logical truth that people won't look for things that they don't believe to exist, and it isn't in peoples' nature to give the benefit of the doubt to a "solution" that doesn't seem to promise to do the job. You are more likely to succeed with reusable elements if the information about them is “pushed”.

There are any number of methods getting this right in an organisation. These range from wiki pages with an RSS feed providing update information, useful in very large teams, to e-mail announcing version updates in the source repository. In a tiny team, the designer or lead developer might telling his colleagues personally, or shouting it across the office might be enough.. Ultimately, whatever your process for communicating about reusable elements... make sure you have one, don’t leave it up to chance.

B] Depends on skills and training. Of course are always those people who (to use Donald Knuth’s terminology) "resonate" with coding and design. We have all worked with them, the gifted developers and architects whose speed and depth of understanding is impressive, even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught.

People, and particularly developers, will tend to prefer to solve problems themselves rather than ask. Asking how something works is a sign of weakness, or even an indication of ignorance, so if there is a way of getting the library to compile, or “hacking” a result out of a framework, your average software creator will do that.

They might not know of the particular design pattern used in a design, or fully understand the inheritance model that the framework designer intended them to use. They need to be given easy access to that information in the form of up to date documentation, or even better, training. A little training goes an enormous way to ensuring that everyone is on the same page when it comes to re-use. Don’t depend on people to ask for training or train themselves, to many people the pre-requisite of structured learning can be seen as an impediment to quickly reaching their target of producing something that works. Make sure you have or a clear route to information and competency with your reusable elements. A learning path which is easily accessible and attractive will encourage people to gen themselves up. Obscure information or complicated training recommendations, will encourage them to try and solve the problem some other way.

C] has a lot to do with the maturity and personality type of your individual team-members, “Better than doing it themselves” means different things to different people. The “young guns” on your will always want to write things themselves because it appeases their ego, whereas your more experienced people might be more likely to accept someone else has given thought to the problem domain and might just have something to offer with the solution.

It also has a lot to do with taking care of A] and B], though. Informed and skilled developers will more happily take the smart, lazy approach of reusing something that they perceive will get them to a solution faster. A “young gun” with new found skills in your particular framework, or newly armed with knowledge about your service layer will believe he can produce a good fast solution (perhaps better and faster than everyone else). The mature developer will be equipped with everything he or she needs to do the right thing in the shortest time. If your team are not equipped with the information they need, of if the information they have doesn’t immediately suggest to them that the existing framework, library or architecture will do the job, they will default to the natural, human position. If they don’t perceive that there is anything to reuse or that what is available will help, then they will build it themselves.

And you will pay for it.

By [[Jeremy Meyer]]