Scientific Method(ology)

Friday August 25, 2006
I'm an empiricist at heart.  It's hard to integrate the principles of scientific discovery into one's daily life; while it makes for a good ontological basis for existence, it has the unfortunate side-effect of being damned expensive to apply consistently.  Still, I try when I can.

Recently it occurred to me that UQDS (Divmod's development methodology) has a striking similarity to the scientific process.  I can't find something that neatly lays it out like I remember learning it in school, but wikipedia has a very nice treatment of the whole process.

As I understand the process of scientific knowledge acquisition, there are four phases:


  • A hypothesis is developed, which is an idea that might possibly be true.

  • An experiment is designed, and performed, to test the hypothesis.  if the experiment fails, a new hypothesis is designed.

  • The experiment is documented in a paper and published, and the publication is subjected to peer review by other scientists; the experiment is repeated.  if the experiment can't be repeated, the experiment must be re-designed to eliminate errors or an alternative hypothesis designed to take errors into account.

  • The hypothesis is accepted as a fact, which may be later be used to develop a model, theory, or even a law.


I know a few of my scientist friends out there might read this, so I want to be clear that I'm not proposing that this is what scientists do: scientists do a lot of things. this is the merest subset of the process required for things to be accepted as "scientific fact", and only in the abstract sense.  Different scientific communities have different official standards.  Still, any new scientific discipline would probably have to start with these rules first to be considered "science", and then probably develop additional ones later.

UQDS corresponds rather directly, as if a code repository were its own particular branch of science.


  • hypothesis: a ticket is created, which is a feature which may be possible to implement correctly.

  • experiment: a branch is developed, which includes test cases.  here, as the test cases fail, the branch is refined and the ticket adjusted, much as the hypothesis must be adjusted.

  • peer review: well, uh... peer review.  Another developer reviews the branch, and verifies that the tests test the hypothesis, runs the tests (replicates the experiment) to verify that they pass for them as well, possibly in a different environment, and reports their findings as well.  If the tests fail, the branch must be adjusted more.

  • fact: the changes are then accepted for merging, where they are incorporated into the codebase, which corresponds to the scientific body of knowledge.