What techniques do you use to maximise code reuse?

Question

Some years ago I was told about a study into code reuse. Apparently it was found that, on average, programmers have a 7 minute window when searching for code to reuse. If they don't find code that suits their needs within that window they'll write their own.

This was presented in the context of needing to carefully manage your code for reuse to ensure that you can find what you need within the window.

How do you (individuals and organisations) manage your source to make it easier to reuse? Do you specifically maintain a reuse library? And if so, how do you index it to maximise your hit rate?

Answer 1

A complex question:

• Some parts of the code can be generalized as libraries or APIs. We have a common library which is kept up to date with solutions to common problems. Typically: validation, caching, data access classes, logging, etc...

• Some parts are application specific. They cannot be generalized easily. We convert them in HowTos and give internal presentations. Code is also recycled by use of an easily browsable SCM (in our case SVN).

• We also have tools that generate code that one one hand cannot be recycled, on the other it's always similar (think calling a stored procedure).

• Pair programming is also a useful way to spread knowledge of existing solutions. We use that when possible or appropriate.

• The last technique is tuition. Each coder has a tutor to refer to. Since the tutors are few, there is a lot of sharing between them and this knowledge can be diffused in a top down manner.

Answer 2

Refactor mercilessly and hope for the best.

Update (4 years later and hopefully wiser)

• Like S.Lott's comment says: Pay attention to Naming. Spread the word to all 'committers' in the team. Good names make things searchable and thereby reduces duplication.
• Have ONE way of doing something and keep it ACCESSIBLE and SEARCHABLE.
• Write code for the average (L.C.D.) programmer.. Don't be clever where simple would suffice. (That includes design-pattern shoe-horning compulsion and related disorders)
• Adopt a common set of conventions, styles, guidelines, standards, et.all early. Ensure buy-in and thereby compliance within the team. (This means everyone uses the tabs (or spaces)!). It doesn't matter what you choose - the goal is that the code should look consistent
• Have a gatekeeper (respected by the team), who eyeballs all check-ins for red-flags.
• Write code test-first / outside-in. This usually ensures that your code is usable by multiple clients. (See GOOS's bullet on context-independence)