Every introductory course in software engineering talks about object-oriented software design and the benefits of code reuse. I still remember the lecture from my first programming class. Looking back I realize that the instructor failed to address why, in practice, software is rarely reused. I believe that the reason that code reuse is not more prevalent has to do with the fact that at the end of the day, it is the code itself that is being re-used, rather than higher level abstractions. Instead of writing code that adheres to a specification for reusable code, engineers are copying and pasting code snippets.

To be clear, there is a lot of code reuse going on out there. Open Source Software is successful because largely because of reusing code. It is not my contention that it doesn’t happen at all, only that it could happen a lot more.

The problem is that code reuse doesn’t just happen naturally. Reuse must be a core element of the design to be made possible. It’s true that software libraries can be intelligently constructed with well thought out interfaces that correctly hide the parts of the implementation that shouldn’t be visible. However, it takes a seasoned programmer to implement this in an intuitive fashion. Even if you are the consumer of a well-designed library, there’s a pretty good chance that its interface is not going to be part of a standard for related libraries. So, if you wish to test out different implementations you need to modify your own code each and every time.

A good example of this is the many different XML libraries out there. Personally, I’ve experimented with Axis, Axis2, Woden, WSDL4J, WSIF, and Xerces in the past few weeks. Many of them have overlapping functionality but implement different interfaces and different usage models (I’ll refrain from sharing my hours of pain using all of them. Maybe that will be another topic for a later post). In order to test each one out, I had to create a new project in Eclipse, import the correct libraries, and modify my base template to use the different interfaces. With just about every package I tested I encountered a frustration and developed a lack of trust in the library that I was using. Granted, this lack of trust derives from what I consider some poorly designed libraries, but it was enough that we re-wrote some specific functionality because we didn’t have the control we needed with any of the individual packages.

Our experience was by no means unique. Jo Woodison documents several reasons for the elusive nature of code reuse. Those that are most relevant to our work include:

• Insufficient means to identify candidates for reuse in the development process
• Lack of available components to reuse
• Lack of flexibility in available components
• Lack of tools to assist with implementing a reuse strategy
• Lack of trust, the “not invented here” syndrome

Another reference to a really old (1969!) article titled “Mass Produced Software Components” by M.D. McIlroy touches on some of these same topics, notably the lack of a market for small software components where software components are analogous to nuts and bolts in the manufacturing industry. Granted, the nature of software has changed a bit since then, but this main thesis is still applicable, and we have yet to see a complete solution. Sharendipity is creating that solution for programmers as well as non-programmers by providing an easier way to build and share applications.