Rethinking Reusability

What happened to the promise of reusable content and the concept of reusability?

It is the opinion of many vocal eLearning developers that although “reusability” is an attractive idea, in practice it has failed miserably. I won’t argue that it is difficult to apply but let’s not throw out the baby with the bath water. Perhaps we need to see it with a new set of lenses. Before throwing out the baby, I would also like to throw in a formal definition of reusability — that reusability is the ability of an object to achieve multiple outcomes across multiple contexts with attributes of deployability, component reuse, and individual reuse. This concept also incorporates the availability of (or sharing of) objects for others to use, meaning that in a learning context, when learning content is used in one context it is also available for use (or reuse) in another.

By what criteria is something — be it a digital object, a design model or even a physical object — reusable? Engineers may look at this from the world of object oriented programming or service oriented architectures. Pulling from the engineering world, those of us who work with knowledge management systems and we who design modular learning content (or design anything) can come to agreement that there are three characteristics that determine the degree to which something is reusable. These characteristics are granularity, abstraction, and coupling. How and to what extent each applies within a particular knowledge domain or context and how they are related to one another determines how reusable an object or design is.

Granularity is commonly thought of as the size or (more appropriately) the scope of intended use of an object.

In building a house, a brick is an object with a small intended scope. It is designed to be used as part of a larger collective, together producing walls, a fireplace, a chimney, etc. If you were to purchase a prefabricated fireplace, for example, the scope would be much larger than a single brick as would its granularity. Another example of granularity is that of an article in a magazine versus the magazine or a chapter within a book versus the whole book. In some texts (e.g. the Bible or other religious texts) the granularity begins with the verse. In the example of the Bible, it is easy to see how this relates to reuse as Bible verses are quoted and used independently of the book everyday. This also points to the next aspect of reusability: abstraction.

Abstraction is the characteristic of becoming context agnostic.

Here is where I will lend detractors to the idea of reusability some credence: nothing ever really exists without some context. As an alternative view, I propose that things can be designed with multiple ends in mind, keeping their various applications, collectively, more generalized than contextual. A brick is seen as being abstract in its design. It is basically a 3-dimensional rectangle composed of a hard material (fire-baked clay/straw). However, as abstract as it may seem, it has design features that lend itself to specific applications or others. Nothing will be completely abstract as usage is also a component of the user and the user’s knowledge and intentions. Moving ahead with the Bible example, this characteristic may tend to foster educational and political debates about religious intentions – usage out of context. The content was not designed to stand alone but is part of a collected whole. The key word here is design. To capitalize on abstraction for reuse, it must be designed that way. Also, it is commonly thought that the relationship of abstraction to granularity is orthogonal (unrelated). Objects that are highly abstracted tend to be smaller in granularity. However, this isn’t always the case.

Coupling is the degree by which an object is dependent on (or independent of) another to function.

This might be the least thought about (and possibly the least understood) attribute of resuability, but in reality it is its third leg. Taken from the software engineering field, coupling is thought of as the amount of independence exhibited by the design and function of a module of code or software component in relation to others in the system.

In terms of transportation – if you drive a car to work, your car operates and is operated independently of any other car on the road. However, people drive their cars as you drive yours, working together as traffic moving in patterns and behaviors due to a common operating environment. In most cases, your car only operates with you (or someone) behind the wheel. It can be said that cars in traffic are loosely coupled but you and your car are tightly coupled. An example of cars that are tightly (and quite literally) coupled would be the train or subway. In that case, each car can’t function independently and can only work when being pulled or pushed by the engine. Also, in the context of mass transportation, they can really only function as intended if there are several cars together being pulled or pushed.

Beyond software (and cars), this concept has implications for the design of learning systems and learning and informational content. For example, if chapters in a book were written in such as way as to be independent of each other for meaning and interpretation, it could be said that they were loosely coupled. Because of this, writing style and information quality across organizational units contribute and, quite possibly, dictate the degree by which content can function independently or “need each other” to hang together.

Unfortunately, when trying to “loosely couple” written content, it can be tedious, time consuming, and require segues or narrative bridges to ensure readability. This may require looking at the coupling issue based upon something other than traditional learning content. By designing learning resources, content, objects or design models that each can function independently, it is far easier for them to be combined, recombined, or recontextualized.

When thinking about coupling, you also must bear in mind that the more independent objects are, the more they need an infrastructure, communication, or design governance structure to utilize them as a collective. In software, there are qualitative differences in coupling types and even formulas for working through coupling issues. This helps in understanding what is required in the infrastructure, communication needs, and governance structures and can be found in service oriented architecture definitions. In learning technology, these issues are bound by the considerations and needs of learning solutions and should be informed by an understanding or approach to learning.

The considerations need to be made explicit, but it’s the models, designs and content that need to be designed for recontextualization.

The important takeaway is that all models, designs, and even traditional content are subject to these considerations which should be made explicit. To be successfully reused, models, designs and content must be designed intentionally for recontextualization.

Some folks might also call this repurposing but I’m not naming names. 😉

What should be reused?

Using the lenses of granularity, abstraction, and coupling, it is apparent that some things lend themselves to reuse more than others. When I hear a question like “what happened to the promise or reusability?” I want to answer this question, “What things lend themselves to and should be reused, and how can we optimize designs to make that occur?”

If we start with things that are rather abstract (models) rather than highly contextualized (i.e. specific learning content and/or designs), we are now thinking about reuse up front. This begins to answer the granularity question because most likely, we will also be thinking about scope. For example, a model is an abstraction that by definition tends to be small in scope, only including that which is absolutely necessary to convey the meaning of the model. Hence the saying “all models are wrong, some are useful.”

There is a concept called “unit of reuse.” This concept is applied when thinking about a reuse strategy when designing learning solutions and learning content. It incorporates thinking about each “lens” of reusability and can guide how reuse can be facilitated.

A common theme in my previous posts on Learning Experiences and Authentic Assessment is the term “pedagogical model.” I believe that as a unit of reuse, defining abstracted models based upon applied instructional theories and pedagogies (or andragogy for Jay Allen) can support the building of model libraries that can function as design building blocks for learning experiences. The abstraction lies in the model, with models being loosely coupled. However, instantiating the models would provide for contextualization and a more tightly coupled environment for learning resources within the learning experience.

I believe the concept of reusability is still relevant; it just has to be thought of upfront through the lenses of granularity, abstraction, and coupling. What can and should be reused and the unit of reuse should be carefully considered to help ensure success.