The Scientific Method and Software Development
Kent McPhee describes (‘Design Theory and Software Design’, p. 17) the classical scientific method as follows:
Scientists first observe certain parameters associated with a phenomenon, then they derive (via inductive or abductive logic) a theory that models the phenomenon. To be useful, the model must contain detail sufficient enough to motivate predictions about the phenomenon’s future behaviour. If the predicted behaviour is subsequently observed, the theory is validated and becomes a natural law.1
Observe, derive a theory, predict, validate. Isn’t this kind of how software development is generally perceived? You first observe the problem domain, then devise the software system, and finally subject it to reality. And devising the system means going about things using inductive or deductive logic. Anything else would be suspicious.2
1 Now I know that after Popper this has changed, and McPhee points this out further on, such that theories must be stated in a way as to be falsifiable, such that the law isn’t fixed; at any point in the future it might get falsified by a test previously unthought of. But this isn’t the point here.
2 Devising the system implies creating every artifact directly or indirectly related to the final artifact – diagrams, relational database mapping files, GUI glue, actual source code, etc. – as per the language workbenches (or language-oriented programming) concept.