Reinventing The Wheel

Creativity and Software.

Engineering is all about purposeful and effective design, Art will know nothing of that. Yet, software being made of symbolic constructs, creativity is undoubtedly a core constituent of its design, and beauty a sure sign of its quality.

Engineering is about the making of artifacts, software engineering about the making of symbolic ones. Assuming (for the sake of the argument…) a complete and consistent set of requirements with a given lifespan, engineering processes mix reuse of existing artifacts or procedures with the creation of new ones, making room for innovation and creativity.

With regard to software engineering the cases and economics of reuse can be judged according reasoned arguments, but what about innovation ?

Innovation vs Invention

As far as engineering is concerned, innovation is bounded by the achievements of science and technology:

• Science builds symbolic representations (aka models) of the world as well as the artifacts needed to check their validity.
• Technology considers how to build artifacts, eventually (but not necessarily) based upon scientific models.
• Engineering considers how to efficiently build artifacts under given economic conditions.

Engineering of artifacts usually encompasses two basic phases, design and production, the outcome of the former being a set of descriptions, the outcome of the latter batches of products. In that context, innovation may apply to new descriptions (e.g the design of a new weapon or a new recipe), or new modus operandi (e.g the sequencing of tasks).

As illustrated by cooking recipes, designs and modus operandi (MO) are not necessarily supported by symbolic descriptions like blueprints or flowcharts; as it happens, that difference may mark the boundary between craft and engineering, the former based on individual skills and personal transmission, the latter a collective endeavor supported by disembodied documentation.
That distinction may also be used to distinguish between innovation and invention, the former possibly (but not necessarily) a matter of craft passed on through imitation, the latter a collective achievement necessarily supported by symbolic descriptions.

Circle, Wheel, Loops

Invention is not easily defined, as demonstrated by the different ways intellectual property rights, and especially patents, are managed across countries. To begin with, two principles are widely agreed upon:

1. Patents are formal descriptions and therefore belong to the realm of symbolic representations.
2. Patents are not rights to use what is described but rights to exclude others from using those descriptions.

Then, policies differ about patentable subject matter, especially with regard to tangible artifacts (a) as opposed to intangibles like business (b) and computation (c) methods. In other words consensus break down when symbolic descriptions without actual counterparts are considered, which is the case for software.

Even if engineering is circumscribed to the making of artifacts, and business methods are excluded, the problem remains for computation methods when incorporated as software artifacts. In that case symbolic descriptions and actual outcomes are merged into source programs and the distinction between design and production is rubbed out. As a corollary, invention, which was previously associated to the design of actual artifacts,  is now deprived of actual context and can only be assessed within its symbolic realm.

But dematerialized inventions are not patent matter, as can be seen with loops: on one hand, with trustworthy predefined language constructs widely available, it doesn’t make sense to “invent” new ways to program iterations; on the other hand patenting those constructs would force designers into squaring circles. More generally, patenting business or computation iterations as inventions would cast a shadow on an uncountable set of activities.

The answer to this conundrum is the distinction between invention and problem solving, the former to be dealt with by engineering, the latter by design.

Engineering & Design

As far as software engineering is concerned, creativity may target two kinds of problems: enterprise organization and applications development.

Given business processes set by objectives and business rules, the problem is to describe how they will be supported by systems functionalities. Since solutions include the definition of features and use of actual devices they can be seen as patentable subject matter.

That’s not the case when systems functionalities are given and the problem is to design the system components that will support them. Solutions will only deal with the design of software component without affecting external features and use of actual ones.

In both cases, creativity can play in two directions: finding specific solutions to specific problems within the given architectural context; or improving functional or technical architectures. While specific solutions, supposedly not reusable, cannot be considered as inventions, that’s not the case for innovations targeting organizations or systems architectures. Yet, since architectural constructs can also be regarded as solutions to problems, innovations might therefore target architectures capabilities as well as their use.

1. At enterprise level problems are set by business contexts and objectives, and solutions based upon enterprise capabilities: who, what, how, where, when. Innovation can only be assessed in terms of business value.
2. At system level problems are set by organization and solutions supported by systems functionalities: access, persistency, computation, communication, synchronization, etc. New applications can be supported by existing functional architecture or entail innovations which should be assessed in terms of functional metrics and Quality of Service.
3. At component level problems are set by functional requirements and solutions implemented by components design: server, boundaries, storage, middle ware, embedded units, etc. New developments can be realized using existing components, or entail changes in technical architecture which should be assessed in terms of total cost of acquisition and ownership.

At each level, creativity must remain a balancing act between architectural constraints and innovative solutions.

Further Reading

• Knowledge Architecture
• Thinking about Practice
• Abstraction & Emerging Architectures
• Collaboration