Title: Thinking about "reuse"

Sometimes costs are obvious: Joe will be tasked with creating a reusable library of widgets, so the cost is Joe's salary for the six months of development. More often the cost of reuse is hidden. As a developer you will decide to make your object slightly more generalised than it needs to be, or you will allow for some obvious enhancement which is not yet required. In effect you are doing more work than you need to, so the cost is perhaps 20% of your salary.

In either case you should have some idea of when the payback will come - a few weeks? months? Are you sure the payback will come at all? Even if it does come, who will see the benefit?

In addition to the financial cost there is the cost of work foregone. If a less generalised object had been produced in half the time you would be free to move onto the next work item. Economists call this "opportunity cost", it is the cost of not doing something else.

Building more generalised code, frequently (but not always) leads to more complex code. By its nature this is more prone to errors and more difficult to maintain.

Further, can we be sure that the additional as yet unused functionality is tested as well as the functionality that is to be used? If I create a Widget class with three methods, and then I decide to add an extra three methods (which I'm sure we are going to need in future) do I test the second three as completely as the first three?

There are other issues with this scenario:

If these methods aren't used we have wasted our time writing them. Even if they are used, between creating them and using them we have to support them, they represent the "cost of carry" - to borrow another term from economists.

Finally, consider those three methods again. When they are finally used they aren't even being reused - they are being used for the first time! Sure, the Widget object is being reused but are we putting the cart before the horse here?

The next problem with reuse is the very word itself. In part this varies according to your perspective. If I create my Widget class for program Foo, and I use it again in program Bar, then I have reused it because I have used it before. But if you were to write program Bar are you reusing Widget or just using it?

Adding "re" to the front of the word "use" doesn't actually buy us very much. When you got on the number 65 bus this morning, were you using the bus to get to work? Or were you reusing the bus to get to work?

OK, maybe I'm playing semantic games here but when we talk about code reuse we cover a lot of ground:

This list could go on, but I hope you get my point. What is use? And what is reuse? The term reuse is not just overloaded but is actually pretty devoid of any real meaning!

This is a word I like. I was already playing around with it in this context before I saw Kevlin Henney's use of the word in Overload 47. If we are developing an object, a module, a component, or whatever, which we are intending to use in several places, commodity fits: we are developing a piece of software which can be used in various ways.

Commodity also has a nice overtone of trading; we buy and sell commodities. This highlights the commercial nature of most software development.

Another benefit of commodity is that it implies certain properties, interfaces and standards - some commonality. A television is a commodity, we can be sure that in the USA it will use one standard, and in England another - inconvenient yes, but a known issue. We can develop DVD players to work with this interface for the TV, we don't need specialised sets.

Product has similar commercial overtones to commodity but must be rejected for our purposes. The word carries too much other baggage. It implies a complete, or completed, item. Commodity is much more granular.

Although this term smells a lot like management-consultant-speak, I think it is much more accurate than reuse. It clearly states what we are talking about and is free of the baggage that reuse carries.

As the sidebar outlines, the term is already used elsewhere and it can be expanded to describe the temporal characteristics of the transfer.

There are two distinct forms of software transfer that can be identified:

Vertical transfer usually relates to the application domain so it is more common within organisations, while horizontal transfer, which frequently relates to the system domain, is more common between organisations. Program families, as discussed by Parnas [Parnas1976], are akin to vertical technology transfer.

Most of the well-known libraries available to developers (e.g. Boost, Rogue Wave Source Pro, Microsoft MFC, etc.) are horizontal libraries. They deal well-known themes (threads, database connectivity, GUIs, etc.) which developers are actually rather good at solving because we deal with the same problems all the time.

A vertical library inhabits a niche that is less well known. For example NAG's libraries are less well known than Rogue Wave because fewer people need advanced mathematical algorithms. Even so, more developers know about NAG's libraries than know about, say, libraries for computing fuel consumption in cars, because many developers have a mathematical background.

Integration is the process of embedding the transferred technology into another development. We may want to distinguish between a donor project (where the technology comes from) and a recipient project (where the technology is used.)

IP is the stuff that technology businesses are based on. Increasingly, this is becoming a commodity as patent databases are set up and companies are encouraged to place their property on line for others to buy. In the hardware world this is established practice - think of the way ARM has built an entire business on the licensing of its CPU technology.

Software can travel the same road. Our intellectual property is expressed in terms of source code, UML diagrams and documentation - although a significant part is still locked up inside developers' heads.

When we use a third party library we are not just avoiding the need to write some code ourselves - we are actively seeking to use others' work. For example, rather than try and understand the mathematics behind optimisation theory I just go and buy the work NAG have done; I use their intellectual property to save myself time in development, testing and verification.

A word of warning though: some people have taken a dislike to the idea of IP expressed in software. The problem is not with the idea of IP itself, but with some of the patents granted, and enforced, which are giving it a bad name.

Once we start to think of source code as a commodity with the ideas and work contained therein as intellectual property, it becomes natural to think of publishing the work. Once our IP is expressed in a commodity, which may be bought and sold, we need to publish it.

Publishing may be external, we may place an advert in Dr Dobbs and request payments, or it may be internal, we may announce to our company that we now have a library that performs some business function, or may be just publishing at the level of our development group.

To continue the publishing metaphor we may like to think of the initial request as a commission. One could imagine a large company, say a bank, identifying vertical application families with common features, e.g. credit appraisal, and commissioning one development group to develop a commodity solution which other groups could also use.

Once we have our intellectual property, we must ensure it is packaged for delivery as a commodity for publication. We may choose to package it as source code, a shared library, or a service accessible over the internet. How we package it will in part be determined by our revenue model, and by how we wish to divide the market.

For example, look at the way Cola-Cola subdivides its market. Although it is nominally selling the same product (sugared water with flavouring) the pricing depends on the packaging. A 330ml can (sold to people on the move) costs more litre-for-litre than the 2 litre bottle (sold in the supermarket to families at home) which in turn costs much more, litre-for-litre, than the cola concentrate sold to restaurants for sale with food - and where it is mixed with water and marked up.

We may make our IP available as a SOAP enabled web service and charge per use. We may repackage this as a DLL and sell it for a fixed price to a large corporation. Finally, we may enter into revenue sharing deals with other producers who compile our commodity into their own.