The idea of code reuse has been a gospel for many years among advocates of modular technologies: first structured programming, then object oriented as well as other types of programming methodologies.

While it is a good thing that we are able to separate concerns and make our code more modular, there is also a downside is requiring that all our code become
reusable.

If too much emphasis is put on reuse, It is possible that a perfectly good solution just becomes something super complicated. In that case, it can quickly degenerate into a generic piece of code, which requires major efforts to interoperate with other parts of the application.

Design Mistakes

Reusable code can also lead to big mistakes in design. By reusable code, people have the idea of creating code that can be applied in another scenario by doing small modifications. This is how inheritance is used by some developers.

And it becomes tricky because real programs don’t work this way. If you write code that is generic enough to be reused in different scenarios, it may be that it doesn’t solve any particular problem well.

A Better Way to Go

The other way to get code reused is to design it to fit a particular problem well. When that happens, we will start noticing a pattern that can be applied not only to the problem that it immediately solves. Thus, such code can help us finding a more generic interface that could (and should) be used in other situations.

Looking at that aspect of programming, it might be better to talk about the sharing of algorithmic strategies, instead of simple code.

Reuse and Black Boxes

It is hard to reason about an algorithm when all you have to work on is a set of black boxes.

Reusable modules as we have these days work pretty much as a black box. Although they are available in source or binary form, they cannot be easily changed if necessary. Sometimes is true even when we’re working with open source software, due to the difficulty of making changes to a library.

I feel that when we reuse code just as a way of creating more black boxes, we have a less flexible toolbox, that is not easily amenable to algorithmic changes. Several layers of such libraries can make our code to look brittle and inefficient.

Maybe we should look for other ways to create software that is easily modifiable. I think that generic programming, using meta constructs available in languages such as Lisp and Prolog could provide a better solution. Maybe we will see more of this in the future.

Further Reading

Knuth talks about some of these issues on his interview for coders at work.

Similar Posts:

• Should we Write Generic Code?
• Day 19: Avoid Singletons
• How to Create Robust Software Designs
• The Power of Doing the Right Thing
• Why a large code base is a liability