What vs. How

The Duality of What and How

Many software development processes prescribe one analysis phase, when you should figure out what to do, and one design phase, when you should think about how to do it. (The following phase is implementation, when you actually do it, but it is not important right now.) Using this as the only distinction between the phases are very troublesome, as one man's what is another man's how.

You start out with the task to describe what the system is supposed to do. This effort needs to be documented, and your best option is to document it in a formal language that can be interpreted and executed by a computer. Now we have a formal specification in a language of our choice. What makes this specification different from a description of how the task is accomplished in this particular language? Unfortunately nothing.

We could claim that a specification of what we are going to do must not be formal. This means that we will end up with an informal description of what the system should do. The problem is that this description has not gotten us very far implementing the system. The hard work of formalizing the requirements are still left to be done. Additionaly, we have no way of testing or verifying that our informal specification is in fact correct. If you have this mindset, chances are that not much formalization will take place in the design phase either, and all the hard work will be pushed into the implementation phase, when uninformed programmers are going to make all the important and difficult decisions with suboptimal result.

The Rescue

Fortunately, it isn't as bad as it sounds. We just need to be more careful with the choice of words when describing what we want to do in the different phases. The what actually means formalize the requirements, and the how means construct the framework that executes the formalized requirements. What you need to remember is to always capture information in a form that makes it useful as a part of the implementation of the program. This means that we should be programming in all phases of the software project, but at different abstraction levels utilizing different languages.