The perils of whiteboards

Summary 

Building upon the realization that conventional means of software design today amount to nothing more than fancy whiteboards, we examine the pitfalls, disadvantages, and consequences of designing software using such tools.

This post is support material for michael.gr - Towards Authoritative Software Design.

(Useful pre-reading: About these papers)

The means

The conventional means of software design today are:

• Pen and paper
• Whiteboard
• General-purpose shape-drawing tools (e.g. Microsoft Word or PowerPoint drawings)

or, in the best case,

• Box-and-arrow drawing applications that are smart enough to keep the arrows connected as we drag the boxes around the canvas. (e.g. Microsoft Visio)

Unfortunately, even the box-and-arrow apps have no notion of what the boxes and the arrows stand for; thus, they cannot be used for anything other than modelling, which makes them nothing more than fancy whiteboards.

Over the years, various tools and techniques have been proposed to better aid the software design process, including UML, but none of them amounts to anything more than a fancy whiteboard. For details, see michael.gr - The state of affairs in computer-aided software design. 

The drawbacks

One of the immediately noticeable consequences of having nothing but whiteboards at our disposal is the lack of a standardized notation: every architect is free to express concepts in any way they like, and anyone attempting to make sense out of their design has to undergo initiation rituals. (UML attempted to standardize notation, but it is a failure, see michael.gr - On UML.) As a result, software design as conventionally practiced is not easy to communicate. This is, however, the least of our problems.

Here is a list of much more serious consequences of using whiteboards for technical software design:

• Designs often include elements that are not well-defined in engineering terms.

You see this with designs containing supposedly technical but actually quite nebulous entities such as a Persistent Data Store here, a Messaging Backbone there, or a Remote Server over there. Such entities are not sufficiently well-defined to be suitable for inclusion in a technical design.

• Designs often include elements that are completely outside the realm of engineering.

You see this with designs containing human figures representing users, pictures of money representing payments, etc. The presence of such items in a software design usually indicates a confusion between what is a technical design and what is a functional specification.

• Designs often include elements from wrong levels of abstraction.

You see this with designs that mix software components with flowcharts, state diagrams, etc. Notwithstanding the fact that these are also boxes connected with arrows, they represent decision-making logic, which is an implementation detail of the component that contains that logic; as such, they have no place in a design.

You also see this with designs that confuse interfaces with other kinds of relationships between components, such as ownership, containment, inheritance, data flow, etc.

• Designs are not informed with what elements are available for incorporation.

The medium on which software designs are conventionally expressed provides no technical means of establishing, or enforcing, a correspondence between a box as it appears in the design, and the actual provisionable, instantiatable, and runnable software module that it represents. This can be okay in the case of modules that have not been developed yet, but more often than not, a design intends to incorporate existing modules. In the absence of any technical means for informing the design about existing modules, the design inescapably represents hypotheses, assumptions, and approximations rather than fact.

• Designs often prescribe invalid combinations of elements.

The ways in which conventional designs intend to interconnect components do not necessarily match the ways in which the components can actually be interconnected.

• A conventional design may assume that a certain component exposes or invokes a particular interface while in fact the component does not have such an interface.
• A conventional design may prescribe a connection between two components on a particular interface, while in fact the interface exposed by one component is not a valid match for the interface invoked by the other component.
• A conventional design may fancy a connection that goes from one component to another component which is inside a different container. In reality, such crossing of containment boundaries is impossible; especially if it involves different execution environments or different levels of scale, it is complete nonsense.

• Designs are often expressed at an unworkably high level of abstraction.

The level of abstraction necessary in order to guarantee the feasibility of a technical software design is that of the component diagram, which shows:

• The individual components that make up the system.
• The interfaces implemented and/or invoked by each component.
• Connections from interface invocations to interface implementations.

Unfortunately, since conventional means of software design are not informed about existing components and their interfaces, they do not have enough factual information at their disposal to delve into the level of detail necessary for a component diagram.

For this reason, the level of abstraction most commonly used by software architects is that of a block diagram, which might be suitable for abstract architectural work, but it is not detailed enough to give any guarantees about the feasibility of the proposed design.

• Designs fail to capture dynamic aspects of software systems.

Conventional means of software design lack the ability to accurately express dynamic constructs such as:

• Plurality: Multiple instantiation of a certain component, where the number of instances is decided at runtime.
• Polymorphism: Fulfilling a certain role by instantiating one of several different component types capable of fulfilling that role, where the choice of which type to instantiate is made at runtime.

• Designs are often incomplete.

A design may incorporate a component which needs to invoke a certain interface in order to get its job done, but omit incorporating a component implementing that interface. In such cases, the software system cannot be deployed as designed, and yet the architects are free to proclaim the design as complete.

The above long list of problems stems from the lack of technical means of informing the design with what is available, and restricting it to what is possible. This means that whiteboard designs allow the concoction of any chimera (W) imaginable.

For further reading, please see michael.gr - Towards Authoritative Software Design.

---

 

Cover image: Illustration of a chimera by Christie L. Ward, from Wikimedia Commons, used under CC BY-SA 3.0