Geeks With Blogs
Robert's Blog ideas about design and development

A colleague of mine was planning on setting up a calendaring system for their department, and he was wondering if they took the trouble to set it up for their department if all the other departments would want to use it.

All the different departments have their own flavor of the month in terms of langauges and frameworks. Some like PHP and Zend. Some like ASP.NET. Some like Python and Django. The list goes on.

All of us have seen a department re-invent the wheel and do something another department has already done, but their are reasons that this happens.

I have been doing a lot of reading lately about code reuse lately. All the articles focus on the same thing pretty much:

  1. Code reuse in the small (UI frameworks and widgets and other industry wide things) is possible and most people do this.
  2. Code reuse in the large is largely an unsolved problem.

Another point these articles bring up is that code cannot be reused easily or effectively unless the code with the intent of being reused in mind. That is, the code has to be built to be reused or restructured and refactored to be reused. Business logic (domain model) is mostly un-reusable because it is designed with a specific application in mind and not designed for re-use.

The articles also go on to point out that writing a component to be reused takes significantly longer to write than a component for one time use (anybody who's tried this knows it to be true). They also say that you have to reuse code four to five times to get the payback on writing the code to be resusable.

Some of the articles go on to talk about the newb developer phenomenon. Who has come into a development shop, been tasked with maintaining an old system and written a greenfield project from scratch to do exactly the same thing? Everybody should have their hand raised at this point.

The reason for this is threefold:

  1. The old developer did a really crappy job expressing the intent of the old code within the code itself.
  2. The new developer did a really crappy job trying to understand the intent of the old code.
  3. New code is more fun to write than maintenance patches for old code.

There are also other possibilities that may not apply to all projects:

  1. The customer did a really crappy job specifying acceptance tests for the old code (or probably did not know they needed acceptance tests)
  2. The developer didn't hold work on the project hostage until they got some acceptance tests

I feel like I need to qualify the last point. If you are doing Story Driven Development, you don't need to have all the acceptance tests before you start coding, but you should have as many as the customer team can think of at the time that clarify the story and add business value.

Another colleague of mine has been doing some investigation into code review for our group and one of his findings was that the two biggest reasons for runaway projects (projects that never reach acceptance or are never delivered) are:

  1. No acceptance tests. If you don't know what the desired end state is, you don't know when to stop writing code.
  2. Bad estimation on the part of the development team.

The reuse problem is a double edged sword:

  1. Managers (especially those with no prior real world experience developing software) expect the code that their subordinates write to be infinitely reusable with no extra effort.
  2. Developers (especially the younger ones, I know because I was a young developer once too) write code for one-time use. This is usually because the customer wanted the thing yesterday, and because rapid development is fast, fun, and can give you a huge ego boost.

I think services might be the exception to this rule (one must keep in mind that services are designed for reuse almost by definition). Look at how many people use Google Maps.

Knowledge is the most reusable component of software application development. So get out there and learn something from each other. Go to a .NET or a PHP User's Group meeting in your area. If one doesn't exist, start one. We really need to start learning from the mistakes of others and pick up on their technology (if not protected by IP, which is why I think most toolkits and frameworks should be open source, but that's another story). We need to do these things so the defacto standard for web development doesn't stay at writting a shallow layer on top of a database forever.

Posted on Sunday, June 22, 2008 7:14 AM | Back to top

Comments on this post: Code Reuse: Sometimes it Works, Sometimes it Doesn't

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Robery Stackhouse | Powered by: