Design All The Way Down

The central idea here is that in Software there is only design.

In software development the design is the whole point. There is nothing else - there is no element of production, no repeated mechanical operation to produce "things". Everything, from the crudest sketches to the lowest level line of code, is a design.

Creating software is the process of creating the design to a problem. All the expressiveness of computer languages, all the algorithms, all the various characteristics of all of the programming languages: idioms, architectures, frameworks, APIs, libraries, techniques, and the like are ways of expressing designs useful in the solution of problems of various kinds.

Every line of source code is an expression of a design. Choosing this interface or class, this method or that function, whether to write one's own functionality or reuse some existing bit, are design decisions. The conceivers and constructors of software systems are designers.

At every level, from the initial realization that there is a problem to solve or an opportunity to seize, to the final character of code, it's all design.

Every piece of software is a piece of design.

Of course, there are all types of designs. Intentional designs, where the designer is aware of being a designer and acts accordingly. Accidental designs, where the coder is unaware of the principles and opportunities of design and simply whacks code into place without seeing any larger contexts (and there are always larger contexts). Good designs - good on all scales; good for today and tomorrow. Bad designs - they do something, but it may be only sortakinda the right thing. Fragile designs that work today but probably won't work tomorrow with different inputs, or that can't be changed without dire forecasts.

Opposing Viewpoints

The problem with software development is no one wants to admit that it is all about writing code. No one wants to be a code writer, each wants to be a "designer," or an "analyst," or best of all an "architect." Why should we spend our time writing code when we can draw UML diagrams? Why be concerned with low level details, when we can spend time thinking about "bigger issues"? We don't need to hide the fact that we are code writers by using some poorly defined terminology. It is only if we first admit that we are code writers that we then can focus on improving the process of writing code. Software is not design, it is code writing.

In Exploring Requirements JerryWeinberg describes design as "the progressive elimination of ambiguity". He specifically excludes writing the line of code from design, since by that point ambiguity has been eliminated. Deciding what lines of code to write: that is design! Writing them and checking they work is build. (Deciding how to improve them is design again: if you have options, you're doing design.)

I believe this sorted of contrived definition used to create a DesignPhase actually supports my argument. If one waited until all ambiguity had been eliminated before writing a line of code, then no software would ever be written. Although I respect Mr. Weinberg, the idea that ambiguity concerning the intended use of software has been eliminated before code is written is simply not feasible. There is no dividing line between "design" and "implementation," it is all programming. If one accepts that the dividing lines do not exist, then the rationale for phases dissolves; it all becomes the process of writing code.

See TheSourceCodeIsTheDesign.