How far can reuse go?

By Andrew Clifford

The more we reuse software, the more productive we are and the higher the return on the development effort. How far can this go?

We can arrange reuse into a hierarchy which reflects the size and complexity of what is being reused. At the bottom of the hierarchy are documentation, patterns and code samples. These give a good starting point for detailed coding tasks.

Libraries are the next level in the hierarchy. In these, functionality has been encapsulated behind an application programming interface (API). We can reuse functionality by including the libraries in our system and calling the API.

Services are next. Logically these act like libraries, but are physically different because the functionality is implemented on another system. So we are not just reusing code functionality, we are also reusing the implementation and operation of another running system.

Package software is next in the hierarchy because all the functionality is reused every time the system is implemented. The highest level is where the software is made available as a service. You don't need to code or install anything; you just use the already running system.

As well as the size and complexity dimension, there is a dimension for how well the reused functionality deals with different situations, or how generic it is.

At the bottom of this dimension is code that deals with only one set of requirements. Going up a level, the libraries, objects or services behind an API might be able to do multiple things, and you specify what they should do by passing parameters in the code.

The next level does away with the code. Your data is held in or presented through an engine, and metadata associated with the data dictates which code to call and how to parameterise it. The engine provides a truly generic application, and you only need to describe your data to the engine for the engine to process it.

Looking critically at our Metrici Advisor software, we attempt to achieve high levels of reuse in both dimensions. It is an already running system. It is metadata-driven, and can be configured for any purpose. However, I do see some limitations. Although it is very productive and versatile, more complicated uses inevitably require significant configuration. Are we missing a further level of reuse?

It is certainly possible to imagine another level of reuse, which does away with defining metadata, and replaces it with an automatic analysis of the data itself, applying rules to work out how to perform basic processing, and where necessary asking and learning from user preferences.

This is an intriguing possibility. It is one in which, instead of analysing requirements and designing systems up front, we encapsulate analysis and design rules in the system itself, which can then automatically configure itself from the data that is presented to it. Although it may not seem it, a highly-reused, data-driven system like this would get close to the all-capable, self-programming computer of science fiction.

The more I think about it, the more I think it is possible.

Subscription