Jun 6th, 2007
Code Reuse is Hard
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.
There is an excellent discussion of code reuse in “Facts and Fallacies
of Software Engineering”, specifically Facts
16-18.
I tend to agree with the points made in the above mentioned book.
Developing truly reusable code “in the large” (as they call it)
requires a constrained domain and multiple iterations. I don’t think
it’s possible for truly reusable code to spring forth from an initial
design.
Thanks, Adam…. One solution to reusable code “in the large” is to abstract the code so more people have access to its functional or artistic capabilities. The challenging aspect of reusing pure code is that it requires a programmer to integrate it or find new ways to extend it.
But what happens if the code is abstracted, and non-programmers are capable of reusing or extending it? If code can be encapsulated in a visual way with well-defined, configurable inputs and outputs, there is an opportunity to reuse code in a much broader application space. Even code/functionality that is deemed “domain specific” will find new uses - that’s what creative people do. Given the wide variety of user generated content online, we can see that there is no shortage of creative individuals in the world. Only a shortage of tools.
The captivating thought using a gui interface for programming seems to creep up frequently. I have yet to see something that exemplifies a true gui based programming environment. Maybe the root to this problem doesn’t lie within the modules or plugins but rather the core of any suit. It’s very possible that a gui based core is what really lacks not the gui objects used for interaction within the core application/components. If there were simple a way to provide this manipulable core via a gui, you would see an even larger bombardement of applications flooding the niche software markets. You could easily fill in the gaps of programs like power builder and VB. Also, the current issue of large build sizes would be done away with. That’s to say, when the core components are built, only the code actually used would need to be compiled, saving a great deal in both size and execution on both the compiling and the final products execution time.
I think that more practical tools will definitely lead to more innovation.
First, yes, XML libs are not known for their user-friendliness and ease of use.
But, I wouldn’t make the Java XML libraries the sample for your conclusion that software reuse is hard, these are some of the most complicated libraries around, probably because the standards are in flux. Also, you’re comparing a bunch of libraries that are for different purposes, Xerces provides support for Axis, but Axis is for developing Web Services, etc, I wouldn’t expect their interfaces to be similar.
I further would disagree with the statement that the libraries are designed poorly, Xerces for example has gone through at least 2 maybe 3 complete rewrites since it’s start out as XML4J, and originally had a package name ending in .jp.
However, this is not to say Web Services, and the supporting libraries are simple. Yes, overly complex, for what you are doing perhaps, open source follows the “scratch an itch”, it may not be designed for you.
I’ve always thought Microsoft had it much simpler. One database: SQL Server. One Web Server. No app server
One framework. And one parser: MSXML, take it or leave it.
You might want to look at JAXP.
If you don’t need that complexity (and few do), then take a look at JSON for some alternate ways of achieving the same thing.
Software reuse is hard, but I find it a bit naive to say no one is doing it. I think you’d be surprised at the acceptance and use of open source software in companies today, Struts, Hibernate, JUnit, Cruise Control, Xerces, Xalan, FOP are just a few examples.
On the other hand, folks are always finding ways to do something simpler or better, see TestNG vs. JUnit. Even then, they see farther, standing on the shoulders of Kent Beck. Somewhere I recently read that with programming it’s important to take a first step. Then the next programmer comes along, and says, what a bunch of crap, why didn’t those idiots just do it this way? But they never would’ve been there, had the original code not been written.
The same translates to software - why did DHH invent Rails, when there were so many top quality Java web frameworks around? Digg vs. Slashdot. Perhaps Sharendipity does something better than Facebook, I’m guessing? Well, best of luck, better than your experience with XML and WS libs hopefully..