> When we make software, in practice, we have to construct the software and test the artefact, hoping that our tests are adequate. We can't do meaningful checks

> When we make software, in practice, we have to construct the software and test the artefact, hoping that our tests are adequate. We can't do meaningful checks on the design itself, let alone on any sketch which prefigures the design. But we can do meaningful checks on the design beforehand, and we can create high-level sketches of a design. We have tools from computability theory, complexity theory, automata theory, graph theory, etc. We have tools for formal specification and verification. We have tools and principles for designing software components and their interactions. We have experiences from past projects that we can draw upon. We can do research, and we can readily discuss issues with other engineers all over the world. I (and I suspect that I'm far from unique in this) do these things in the early stages of every project. My boss will come to me with a list of requirements, and some requirement(s) will invariably be intractable in terms of computational complexity, and I'll have to sit down with him and work on a compromise (most often, it's a case of the client trying to describe the solution they invision rather than the problem they need solved, and once we've determined the rationale for a requirement, we can come up with an alternative that fits the bill easily enough). After all of the requirements are both computationally possible and tractable, I come up with a design sketch to illustrate the architecture of the application at a high level. I identify the major components and how they relate to each other, and I identify the flow of data for each her case and what happens to it at each step. I describe what extension points we'll need in order to accommodate the addition of functionality that didn't make the cut for the first iteration, but that we already know to be needed in a future iteration.