Software projects as scientific explorations

Some ideas about scientific exploration as a metaphor for software projects: Scientific exploration doesn’t take place in a void; there’s always a starting point, something to relate to. But there’s also something unknown that is explored, that we want to learn about.

With this metaphor, we conduct experiments to prove our hypotheses (as per the scientific method). One way to do this is to express the hypotheses in code, either as prototypes or by evolving the real piece of software under development, and let the future users test them, such that their feedback either proves or disproves our hypothesis.

Or, we can create non-working prototypes that illustrate our hypotheses, to give the users, or the representatives for the users, an idea of how we have interpreted the specific part of the problem context in question. But then there’s a bigger uncertainty whether a proven hypothesis is correct. So we either gamble, with the risk of having to redo, or conduct more experiments, that hopefully overlap the gaps so that the proof can be taken for granted.

Or, we can talk, write prose, and draw diagrams about our understanding of the slice of the problem context, and take the users’ nodding as proof of our hypotheses. But they might be nodding to conceal the fact that they are dozing off. Or they might have understood our explanation in another way than we intended.

Or, we can just ignore to test our hypotheses, and code against the requirements spec.