Re: code-sharing at work.

In no particular order and with no particular emphasis:

Don't "share" code - reuse code. Create a set of infrastructure modules that everyone reuses.
Document APIs - you can't reuse what you don't understand how to use
Tests - most people rewrite the wheel because they don't trust the other code. Seeing 1000 tests pass goes a long way to giving someone confidence.
Source Control - everyone checks their stuff in and can see the latest versions.
Managerial dictates - sometimes you need a whip to get out of your rut.

Ultimately, you need to soft-sell them on the benefits. If you and a coworker started to reuse each other's code, you can demonstrate how you found a bug in his code that he'd been trying to fix for months (and vice versa). Two heads working together are better than three heads apart, and all that jazz.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Comment on Re: code-sharing at work.

Replies are listed 'Best First'.
Re^2: code-sharing at work. by Joost (Canon) on Mar 23, 2005 at 21:21 UTC
I agree, especially concerning tests and documentation. Documentation is good. Tests are good. If they are done right, it's even better. But hardly anyone wants to spend a lot of time writing tests or documentation, so even just some people documenting and testing bits of the same code will make it better than having everyone go out and re-invent the wheel. Make sure you make it easy to adapt, test and document the code. That's where revision-control comes into play. I'm using CVS at the moment for most of my projects, but subversion is looking to be the best thing since CVS. I've only used it on 2 projects, yet, but as soon as I've got the time, I'm planning on switching my CVS repository to subversion. I would also recommend using some sort of Wiki for "general" documentation (introduction to a module, giving an overview of the whole code library/project) - just because it's easy to change will mean that people will actually update the docs. Remember, programmers should be lazy :-) If it's easier to write a new plain text-file in some obscure subdirectory than to update a word-document in the project-document system, guess what they'll do. Avoid wordprocessors for documentation as much as you can. Programmers hate them: they're big, slow and you can't write code in them. A good Wiki is much easier. updated: spelling. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^3: code-sharing at work. by blazar (Canon) on Mar 24, 2005 at 08:07 UTC
I would also recommend using some sort of Wiki for "general" documentation (introduction to a module, giving an overview of the whole code library/project) Where I work they have recently installed Trac, which is, to quote from the home page, "an enhanced wiki and issue tracking system for software development projects". Personally I find it quite handy, effective and useful both as a web-based interface to svn and as a wiki and I particularly appreciate its terse and clear, minimalistic, look & feel.	[reply]

In Section Meditations