On the Degrees of Reusability

Cedric Beust of Google writes "Four Degrees of Resusability":

I have identified four levels of software reusability:

1. No reusability.  The least interesting of all.  It's typically a standalone application that was designed to serve a finite set of goals and not be extensible by anybody else but its creator.
    
2. Binary reusability.  While the source is not available, binary reusability enables third parties to write extensions to the software.  Microsoft COM is the best example of such an approach, and it's been tremendously successful.  For example, even though you don't have access to Internet Explorer's HTML renderer, you can still embed it in your applications and take advantage of all its power (Yahoo Messenger uses it but you would probably never tell).
    
3. Plug-in reusability.  This is very similar to the binary approach mentioned above but with the difference that the operating system is not involved in the connection between the plug-in and the core architecture.  Eclipse is a good example of such an approach, which can also be used in the absence of the source.
    
4. Source reusability.  The software is shipped with its entire source code, making it possible -- in theory -- for everyone to extend it at will.

It's an interesting taxonomy that I would like to further expand on. The concept of reusability goes hand-in-hand with the concept of modularity. So studying it from that perspective can give us better insight. Cedric makes that astute observation that the order from least reusable to most reusability is 1 < 4 < 3 < 2. In otherwords, unintuitively source code is less reusable than than the alternatives.

This conclusion of course is debatable. Obviously, source code of a plugin is intuitively more reusable than its compiled form. A plugin or a component is a restrictive form of a class. I've discussed this earlier in my definition of a component.

The plugin is also a more restrictive form of a component. That is a plugin is dependent on contracts with its container. Therefore, Cedric sounds correct when he says 3 < 2. That is more flexibility leads to greater reusability. However, why is 4 < 3 < 2? Source code has the most flexibility, the symmetry is clearly broken and most likely the reasoning is faulty.

So let's examine source code a little more. Source code can come in a multitude of forms, from assembly languages to object oriented languages. Computer science has evolved such that contructs like symbolic names, procedures, polymorphic dispatch, encapsulation etc. were created to make it easier to reuse code. Code without structure is much more difficult to reuse. This leads me to a definition, reusability is the degree of effort required to reuse as software artifact. Unstructured source code is definitely more difficult to reuse than source code that is based on a component model.

The absence of source code does make reuse more difficult. However, 4 < 3 < 2 does not hold in general. In fact 3 < 2 does not hold in the context of the right container, that is a plugin is more reusable than a component. Reusability increases as code is made more restrictive, it's an unintuitive notion however its the notion that's akin to encapsulation.

Code to function deterministically requires the creation of constraints and controlled boundaries around various components. However, too much constraints can cut the air out of any reusability. The balance between restriction and extensibility is one that component models try to achieve.

Finally, one element of reusability that is completely overlooked is the one identified by Butler Lampson. The thesis is quite simple, reusability is happening all over the place. That is software development continues to reuse "big components" in the form of an operating system, the relational database, the web and so on. His point is that the platform is the reusable component not the otherway around.

Therefore, reusability in the absence of a container/platform is relevant only to a subset of components. Pure functions are context free and can be reused in almost any context, however that deviates from the point. The point is how much effort is required to incorporate a software artifact to achieve the desired functionality. Reusability in the absense of the notion of packaging simply doesn't make sense. It's all about packaging and packaging can not be divorced from platform.

In conclusion, reusable components reduce the effort to develop functionality. To achieve this one needs to focus on packaging, it has little to do with availability of source code. Just ask Red Hat who built a billion dollar open source company on top of an installer (i.e. RPM).