So what is Code Reuse?

Before we can talk about code reuse, it's important to understand what it is. It can mean many different things to different people.  I found this out while researching this article.  I interviewed several different people ranging from developers to software process engineers to managers, and everyone has a slightly different take on the concept.  I found there were two extremes.  One was that code reuse isn't practical in the real world and pursuing it is a waste of time.  Another view was that all coding could be considered reuse because almost everything starts from something else.  These days, virtually no code is written from scratch.  Which view is correct?  Depending on your view, the answer lies somewhere in-between.  It should also be pointed out that code is not the only thing that falls under the umbrella of reuse.  What about design and process documentation, procedures and the implementation of software tools? These are also items that can benefit from reuse.

The simplest form of reuse is basically copy and paste.  You take some code that has the functionality you want, and you paste it into your code.  This is probably the form that's most commonly used because it does not require any real planning and can be done on the fly.  This also can take place at the project level with a complete set of files.  Every new project that I have started on has taken an entire code base from an earlier project and used it as a starting point.  Many would argue that this is certainly not code reuse because you end up having to make a lot of changes to the code before you get even close to your design objectives.  It can also be dangerous if you don't know much about the code you are starting with.  How well was it written?  Has it been tested?  How much time is really saved by starting with something that needs an unknown quantity of change to meet your objectives?

Most would agree that real code reuse should result in a reduction of coding time and maintenance.  It should enable the user to plug in existing code that is reliable and abstract enough to be useful in many situations, but specific enough so that not much needs to be modified to produce the desired functionality.  It should be well tested and bug free.

Since the dawn of the software, the concept of reusing code has been reinvented several times.  Procedural programming provides some code reuse because you can write a procedure and reuse it as many times as you want.  However, the concept of reuse became even more powerful with the advent of Object-Oriented Programming (OOP).  With OOP you can go an important step further by creating relationships between classes through inheritance.  Your code can be designed in such a way that new classes can be created from existing higher-level classes that pass on common attributes.  You still have to add in functionality that is unique to the new sub-class, but you don't really have to change anything else.  You can also reuse code at a higher level through the use of Frameworks using abstract classes and standardizations.

Code reuse benefits and implementation are also heavily dependent on the type of projects themselves and the complexity of the code.  There are always common functions that are shareable without needing to change, but generally the more complex the code is, the more changes will have to be made to meet requirements.

Unfortunately code reuse is not always practical in every case.  Many times it is not even considered when developing a system.  This approach results in a system that is too specific and has too many internal dependencies to be used in other applications.  Real code reuse is also often short circuited by schedule constraints, limited resources and budgetary concerns.  Many well-intentioned development teams know they should start with a reusable design, but the payback for this effort won't be seen until much later.  In most cases, those who are funding the project aren't thinking about the next project yet, they just want to get the current one out the door as soon as possible.  Unfortunately most managers do not recognize the investment value of the initial design effort.  Even if they support it, they might not be around long enough to reap the rewards, so why bother?  Let the next poor slob deal with it.

It's also hard to quantify how much code reuse is saving time and money.  You can use tools to count lines of code before and after you implement reused code, but the end result can be misleading.  How do you account for lines you have removed?  Many times you have to rely on developer's opinions as to what percentage of their code was reused.  It can be difficult to put together hard facts to sell the concept to the one holding the purse strings.

If you are lucky enough to have the resources and the management support to utilize proper code reuse, how do you implement it?  Solid configuration management practices and tools can help.

As already mentioned, reuse of code is not the only type of reuse you can utilize.  As a basis of a solid reuse policy, you need to have strong policies and procedures that back this up.  It helps to have an organization wide coding standard.  Understanding the coding conventions used make sharing any code much easier.  In addition to the software, all project level documentation should have templates available where new projects can take advantage of the way other projects implement policies and procedures.  Holding peer reviews for code design also helps.  The more communication there is among different development teams, the greater the awareness of reuse objectives and success stories.

How you store code is also critical for reaping the benefits of reuse.  Your configuration management libraries should be constructed in such a way that makes shared code available to all development teams.  If physically locating shared code is difficult or complicated, people won't use it.  The design of your library structure and the implementation of your SCM tool are critical in implementing ease of access.  Sometimes this is hard to do if the libraries and the tool are already in use, but it is very important to make it as accessible and simple as possible.

Many software configuration management tools have ways that they support reuse and you should investigate the ways that your tools support this.  I personally have experience with Merant's PVCS Dimensions and Rational ClearCase.  Both of these tools have different ways of supporting reuse.  For example, you can create a ClearCase administrative VOB (Version Only Base, a ClearCase database) that contains global objects (such as a branch type or label type that is shared across several projects).  As new projects come along, new VOBs can be created from the administrative VOB that inherit the global objects.  In PVCS Dimensions, you can define all the aspects of a project using a process-modeling tool.  This model can be exported and used in the creation of new software projects, so you can create a template that has common attributes (such as item types, roles and object lifecycles) that are used to start up new projects.  Many other tools have ways that this type of sharing can be promoted.  One great way to find out how others might be doing this with your tool is to post the question on the CM Crossroads web site.  Many tools have their own threads on this site where you can discuss these kinds of issues with other users like yourself.

I believe that implementation of code reuse is a reality and not just another process improvement story of the week.  However, like most good things, it requires a lot of discipline, planning, and up front investment.  It is also critical that solid SCM practices and tools support reuse efforts.  It's hard to move fast when you're driving on a rough road.  In the case of code reuse, solid configuration management provides the smooth pavement for a better ride.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment