Take the 2-minute tour ×

As a team lead of about 10+ developers, I would want to promote code reuse. We have written a lot of code-- a lot of them are repetitive over the past few years. The problem now is that a lot of these code are just duplicate of some other code or a slight variation of them.

I have started the movement ( discussion) on how to make code into components so that they can be reused for the future projects, but the problem is that I afraid the new developers or other developers who are ignorant of the components will just go forward and write their own thing.

Is there anyway to remind the developers to reuse the components/ improve the documentation/ contribute to the underlying component instead of duplicating the existing code and tweaking on it or just write their own?

How to make the components easily discover-able, easily usable so that everyone will use it?


I think every developer knows about the benefit of reusable components and wants to use them, it's just that we don't know how to make them discoverable. Also, the developers when they are writing code, they know they should write reusable code but lack of the motivation to do so.

share|improve this question
the only approach having a chance to accomplish this is code-review –  gnat Nov 8 '12 at 8:07
Reusing components within one project is great idea. Reusing components between different projects can result in disaster. If you want to create a components that are reused between projects, then make a new project for them and manage them as such. –  Euphoric Nov 8 '12 at 8:19
@Euphoric: +1, couldn't agree more –  Andrzej Bobak Nov 8 '12 at 8:40
@Euphoric, that's something that I would do, but this along doesn't guarantee that people will use it –  Graviton Nov 8 '12 at 9:33
I think How Visual Studio could help to avoid duplicating code? is not duplicate, because it's worded as more specific, but it has a really good answer that is really applicable here. –  Jan Hudec Nov 9 '12 at 7:56
show 1 more comment

4 Answers

You need documentation, a proper one. It should be easy to find and navigate. You also need discipline. If there's already a solution provided in your reusable code libraries but the developer chooses to use his own solution instead (without any proper reason), you should revert his solution and tell him to use the existing solution.

I also agree with Euphoric's comment to the question. It's often impossible to reuse anything between different projects (usually all the CRUD operations look the same, but usually you can't reuse them).

share|improve this answer
You need documentation, a proper one. It should be easy to find and navigate-- any tools suggestion for this? –  Graviton Nov 8 '12 at 9:19
Confluence? Wiki? Good auto-generated site with javadoc contents? Developer's guide document? Every developer should spend time getting to know with the contents of the documentation and signing he/she is familiar with the content. –  Andrzej Bobak Nov 8 '12 at 9:50
You have used any that you find is useful? –  Graviton Nov 8 '12 at 10:01
I used confluence. It worked for me. –  Andrzej Bobak Nov 8 '12 at 13:27
add comment

I think the best way to actually make them reuse code is motivation. If you put the reusable components in extra projects, like Euphoric suggested, put much effort in it. Where I work, we made a project, that runs a set of predefined interfaces in configurable executionplans and provides a few services (e.g. different classes for DB_interaction, an FTP-Service, ...). The project is a big success, because our developers actually want to use the micro-framework, because it is saving them a lot of time for writing boilerplate-code for similar projects. The same thing is for Utility-libraries for Lists, Strings, etc., but in this case you would want to use existing once. (why reinvent the weel?)

Conclusion: Let your developers experience the benefits of well-tested reusable components. But I also agree with the answer of Andrzej Bobak: Many things aren't reusable, because they are similar, but not the same.

share|improve this answer
I think everyone knows about the benefit of reusable components and wants to use them, it's just that we don't know how to make it discoverable. Also, the developers when they are writing code, they know they should write reusable code but lack of the motivation to do so. –  Graviton Nov 8 '12 at 10:27
For the Listing of these Projects we have a wiki, but I have to admit, that most of the time people just talk to another. To find out what is actually worth to put in a component, you'll have to do code-reviews. And if you found out, which Code is duplicated very often, I'd declare a project and give it to the developer, who wrote the code. –  Regular John Nov 8 '12 at 10:41
add comment

This is going to be difficult, because people like to write new code for simple components and they like doing it their way. It's much harder to leverage an existing solution and extend it, than to write a completely new implementation with the new requirements. What you need to do, as has been stated, is start a code review process among the team to help identify situations where an existing components should have been used/extented instead of a new one.

You also need to maintain a very good and thorough documentation so that people can refer to it and easily find what they need. If the documentation is incomplete or out of sync with the real thing, people will not be motivated to search through it or enhance it.

As the team lead, you should also encourage people to ask themselves if a similar component exists before creating their own and direct them to the documentation so they can look it up. Sure the code review process will catch it if someone missed an existing component, but what if they already put 10 hours of development in their own implementation? You need to avoid these situations by enforcing good research behavior in the team.

share|improve this answer
add comment

Beside the already mentioned factors "documentation", "easy to find and navigate", "discipline" and "codereview"

resusable code must be

  • easy to use (= need examples i.e. unittests)
  • without too many dependencies to other modules and
  • it must have a stable api so i donot have to update my aplication to use the library.

without the last two items it is much easier to use "copy&past-inheritance" that we do not want.

share|improve this answer
add comment

Your Answer


