Contribution 30

From WikiContent

(Difference between revisions)
Jump to: navigation, search
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]]

Revision as of 17:23, 13 July 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 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

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.

c) Are convinced that its better than doing it themselves

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.

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