Software developers create an intangible product — software — to define the initial configuration of a processor’s memory. The right memory configuration causes a processor to do what it’s supposed to do.

We all tend to refer to the text representations of code as ‘software’ — when in fact, this text is just one step in a process of getting from a user need to the right memory configuration. The steps between articulating a need and delivering a completed software module contain many artifacts that represent the software.

High-level constructs have had widespread use as software design and documentation tools for a very long time. From functional block diagrams to Unified Modeling Language (UML) and SysML, the idea that ‘a picture is worth a thousand words’ has had its place in software development. But if you really need to know what’s going on, don’t you, like everyone else, want to look at the code?

But in some environments, there isn’t any code to look at. For example, think of the software that configures programmable logic controllers (PLCs) in industrial automation systems. The ladder-logic representations of sense-and-act conditions and sequences are the only representation the PLC programmer needs — and this has been a primary way of programming these special purpose computers for many years. And that can be a good thing, for example, enabling creation of development tools that enforce specific ladder-logic design rules for safety-critical systems.

Other environments in which software can be generated without handling source code include several where graphical blocks can be associated with code elements. Software engineers connect the blocks to make a model and define the execution and data communication logic between the code elements. Press the button to translate the diagram into software. I remember being mildly surprised when some years ago, the head of development of embedded automotive software explained their team hardly ever used ‘code’ any more, everything was developed with diagrams.

Configure or program?

Many simulation systems used in (real) product development implement graphical interfaces. These allow representation of systems by connecting the diagrams that represent each of the components. The resulting simulations can be complex configurations of simulation software, sometimes integrating multiple independent software.

Business intelligence software offers similar capabilities, for example, drag-and-drop data items or whole databases to define data sources to display or correlate.

These examples trigger a question — where, if it exists at all, is the boundary between configuration and software development? And if this boundary does exist, does it help or hinder software development? Should we be standardizing this interface, or demolishing it?

A developer can ‘use’ an application programming interface (API), but a user needs a tool to help them use an API.

Software engineers have forever appreciated the value of reuse. Services and micro-services offering APIs are evidence of this desire to create software which has value in more than one context.

A software developer is a ‘user’ of existing elements (for example, through APIs), and an author of the new connections between them. Some developers see opportunities to get more done by building tools. Some of these tools are built to allow users to build the connections between existing software elements. The result can look like a new software system.

So, what comes after APIs? Concepts from object brokers, message-based-systems and service registries have something to offer. These approaches don’t guarantee universal connectivity, but can automate the handling of some of the details. This may be enough to allow a user to configure (or should that be develop?) the software they need from components.

Or perhaps this should be seen as development automation, handling the details so that developers can concentrate on the creative and conceptual challenges of new software. If it works well enough, someone will find a way to automate use of general-purpose ‘requirements’ to configure existing modules into a new software system.