Contribution 30

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Reuse of designs, frameworks and components is on of the key drivers of architecture, but ultimately, people are the issue.)
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

Revision as of 12:37, 28 May 2008

Reuse is about people and education, not just architecture

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:

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

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

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

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.

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.


By Jeremy Meyer (Edited RMH 5/28/2008)

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools