What A Butter Knife Can Teach Us About Component Reuse

Consider the butter knife: a piece of metal, thin and flat at one end, slightly rounded at the other. It’s designed to spread...well, butter on a baked good. Now, of course, the original requirements document for the butter knife has been long lost to history, but it's easy to see how spiral development could culminate in such an elegant and purpose-specific tool. And yet, at one time or another, we've all used a butter knife for entirely different purposes. Perhaps as a screwdriver, maybe to help loosen the top of a jar, as a light-duty pry bar, or as a shim. (I can only assume there are additional uses as well.)

This illustrates some very interesting ideas in terms of product re-engineering, bottom-up design versus top-down design, and probably most significant for today's engineering world, product re-use. If we were to look at a butter knife and consider all of its potential uses as witnessed in the environment, could we even come up with the original requirements for that object? Probably not. The idea that it was designed simply to apply butter or jam to a baked good seems laughable. But if we were to consider it from a top-down standpoint, and consider that we wanted the end system, product, sub-system, or component to be flexible and reusable, I doubt that the process that drove us to create the butter knife would in and of itself define all of its potential uses.

Keep in mind that although we are discussing a physical object here, to some degree the same ideas apply to software development as well. While designing a purpose-built CSCI or CSC is straightforward enough, when we consider its reuse, we are limited in terms of our own visionary capabilities and in re-engineering the usage of those CSC's or CSCI's. While the object may be able to provide the capability required for our secondary or tertiary projects, there is no guarantee that we would fully understand the original requirements that created that object (unless we take special care to preserve those requirements and the corresponding traceability).

Why is this important? Well, let's consider the role and responsibilities of the systems engineer at the fundamental level. The systems engineer is responsible for the emergent properties of the system, right? Those properties are ours - we own them. And yet, if you are designing a system/subsystem/component, CSC, CSCI's, etc., it is fundamentally inconceivable that you can have a prior understanding of all of the emergent properties and capabilities that your component or subsystem will enable. You can't because some of the enablement may be secondary, tertiary, or combinatory. You can only begin to understand potential capabilities to be enabled in terms of potential future systems (and by definition, alternative CONOPS that necessitate those systems.)

Therefore, when thinking of reuse, we must try to force ourselves to think in terms of “capability enablers and contributors” and not just pure “capability provision” alone. Oddly enough, this seems easier to do with larger subsystems, but with smaller subsystems, the challenge is that “enabling” in and of itself becomes a system property as two or more components are jointly engaged.

Conversely, if that component is reused in a bottom-up or a reengineering type effort, again, we have limited ways of fully understanding how that reused component will fully create emergent properties. Case in point: house wiring. Think back to when, for a very brief moment (late 1960’s through the 1970’s), aluminum wiring was used for some residential wiring in the United States. Aluminum wiring for residential use seemed to be a perfectly plausible reuse of a known technology. The aluminum wiring, the power outlets, and light switches were all known quantities and perfectly capable of meeting the requirements appropriate to their part of the “home power system.” However, when combined into a single system (using established methods), the aluminum wiring enabled a negative emergent property (e.g. overheating and fires).

Of course, we can always say that by simply understanding Metallurgy 101, “thou shalt not mix dissimilar metals,” the emergent properties could have been identified and managed (via additional system-level requirements), but I would posit that the discovery of this issue was something different (after all, these were smart folks). The focus was on the reuse of a component for a specific result (good electrical transmission quality and lower cost than copper) without fully considering the enablement of new emergent system properties. So what's the takeaway? The takeaway is that predicting reuse under all circumstances is exceedingly difficult. When reuse is planned within a specific construct (e.g. product lines), methodologies, capability, and emergent properties can be fairly well known, planned for, and more importantly, capitalized upon. However, when forecasting reuse in terms of an unknown future, the challenge becomes much more difficult and even hazardous. This therefore requires a deep and abiding understanding and execution of systems-level thinking and systems engineering as a discipline, as well as the rigorous implementation of any discipline-specific engineering that is appropriate to that system, subsystem, or component.

And remember: a butter knife is the exact same thing as a screwdriver – except, of course, when it's not.