Don't do it (share code).

"... You see, this profession is filled to the brim with unrealistic programmers. Programmers who thought their code would age like wine. If you mean it turns to vinegar, it does. If you mean it gets better with age, it don't. ..."

Marsellus Wallace (1994)

During my years as a software developer, I (and a lot of colleagues) have been thinking, talking and trying to figure out how to store and share our code. Code that we have spent time writing in the projects. I have always thought it would be nice if there was a common place to store stuff, to be reused in upcoming projects and shared between teams and local offices. That's a great idea, isn’t it?

No. It's not. It is actually a bad idea.

Recently I had a moment of enlightenment: stored code for later use is waste. When reusing code it creates waste and sometimes even confusion. Waste is expensive stuff. Confusion is risky stuff. Avoid it.

Here's an example:
Back in the .NET 1.1 days, do you remember what we needed to write to check if a string was null or empty? After a couple of projects I ended up writing a StringUtilities class with an IsEmpty method. Happy with the result I added it to a Common Utilities library in our version management system, for future use. If I remember it correctly, I also wrote my full name in the code comments section. (Today I don’t need that kind of confirmation. I have matured. I just settle with someone liking my current Facebook status.)

The next version of .NET of course had the IsNullOrEmpty method built in and that made my String Utilities code totally unnecessary. Too bad the class already had been reused all over the code base in an other project. And now people started to wonder:

- What weird stuff does that utilities code do? Why didn’t they use the built in method? Whatever. Better leave it as it is.

Another example:
Let’s say that we are about to write some c# code that should read RSS feeds and display them in a nice list. Before .NET 3.5, you would probably need to write a custom Feed class, a Feed Item class, and most likely a couple more of those custom classes. You would also need to write stuff that maps the RSS data with your custom classes. Once done, maybe it all should be stored in a Common Utilities folder for future use? 

Don’t do it!

Because in the future people will start to wonder:

- What weird stuff does that utilities code do? Why didn’t they use the built in SyndicationFeed class? I don’t understand. Better leave it as it is.

Both the string.IsNullOrEmpty method and the RSS Syndication namespace are part of the current .NET Framework. Code that is a part of the Framework is stable and (most likely) a lot more tested than our custom made ones.

Fine Code that we write today quickly turns into vinegar. Marsellus Wallace was right.

Okay, so Code is aging very quickly and that sucks. However, good ideas often stand the test of time. I think that we should rather share the ideas, and not the code. Use code only as an example to explain a concept. When understanding concepts, people will find better and modern ways to solve problems.

I think the same goes for Company policy Code Standards and Design Guidelines. Don’t spend too much time writing documents that will be buried forever in the Graveyard, aka the Intranet or Team Foundation Server.

The ideas and practices are better shared at informal lunch presentations and in blog posts. Maybe even in an Open Source project? Once the library or the blog post is out there, I mean really out there (outside the company firewalls and indexed by Google), it will be obvious to the world if it is fine wine (maintained) or vinegar (not maintained).

Got stuff to share? Invite your fellow geeks to a lunch session! Bring your laptop and start talking.


Mr Marsellus Wallace: