Of software bugs and learning curves

Design Education

Software development is a design-based activity. Some people assume design means "drawings and documents about the software, but not the software". However, this is not a particularly useful or accurate reflection of what design-based professions do. Design is about the creation and expression of structure, physical or virtual, that fulfils a number of goals and satisfies a number of constraints. It is a creative and intentional act with many modes of expression and levels of detail.

Goals and constraints can be decomposed recursively from the highest-level of granularity into finer levels of detail. Requirements exist at the application level with respect to its users, but requirements also exist locally in the way that one method uses another [2]. However, there is no simple sausage machine that successfully turns a handful of use cases captured in natural language into an effective running system. Design is involved in everything from framing the requirements to demonstrating the effectiveness of a running system.

Design embraces all the kinds of expression of structure from whiteboard sketches in ad hoc UML to lines of code in Java. This means that the view of code as no more than an implementation detail — and therefore one that is not a proper concern or activity of design — is one of those unhelpful myths that has dogged software development for too long, and yet fails to stand up to close scrutiny.

Code is a formal notation used to express structure and execution in a virtual world — very little code, even that written in something as metal hugging as assembler, can claim to be describing structures and execution in a strictly physical world. Code creates and inhabits a designed domain [3].

A significant number of decisions that affect the final software are made at the keyboard in a code editor. This is not necessarily always a good thing, but it is necessarily inevitable. Any sustainably realistic view of development needs to do more than just acknowledge this inevitability - it needs to take advantage of it.

To understand the inevitability, consider detail: all design activities are in some way based on abstraction, but not all are or aim to be complete. A package diagram sketched out on a whiteboard may be accurate, but it does not offer a complete view of what has been or is to be developed — if it did, it would be unreadable and useless, defeating the very purpose of using such a sketch.

By contrast, the definition of a wire-level protocol needs to be both accurate and precise for it to be of use — a sentence such as "... and the bits ought to be laid out in some order or other" is unlikely to be of much use. Code, in its many forms, is still abstract, but it demands a high level of both precision and accuracy. There is no cheating on the completeness of the detail needed — the variation across various programming languages and infrastructures is with respect to the amount of detail needed, not its completeness.

Of course, this is not to say that all designers are — or should be — equally good at all kinds of design. Such a statement would not be well supported by the facts. However, it does indicate that design is a very broad church that cuts across many different concepts and practices; successful design involves playing on and bridging these differences to best effect.