Contribution 30

From WikiContent

Revision as of 19:38, 18 May 2008 by Jeremyanywhere (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

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
b) know how to use it
c) are convinced that it is better than doing it themselves

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

Personal tools