How doctors and pilots verify

The current discussion around Test-Driven-Development (see here, here and the Hangout) seems a bit far-fetched, as I have rarely seen such dogmatic applications, but some aspects of it are indeed interesting.

Mocking clearly has its limitations (whoever used Spring or O/R mappers knows the uncanny feeling of mocking tons of Spring internals). What I find fascinating more interesting, though, is the cultural discussion of pre-planned versus experimental approaches. In the Hangout, Kent Beck makes a point about how he defines the problem and incrementally finds a solution whereas Hansson does not even define a problem but rather tests something directly with any "owner", prototyping. From their example it looks like Beck usually solves algorithmic problems whereas Hansson seems to face interface and integration issues. Fowler seems to see both advantages, and tries to reconcile without a strong opinion.

The more interesting underlying question is, where verification is required and how it is achieved. This reminded me of a chat I recently had with a friend, a doctor, and another friend, a pilot. The pilot explained, how nowadays conflict resolution between the various (social and technological) subsystems of a plane, also between the various autopilot systems, is a major part of the training. The human mind becomes the reason between algorithms (an argument Lehrer already wrote about, also see Flash Boys). Understanding feedback cycles and how systems interact is of course an important tool to solve conflicts. The doctor added that, interestingly, this systemic understanding becomes more and more relevant in her work. She went on explaining that, just like in software engineering, medicine has a discussion about whether it's more of an art or more of a science. In her opinion, which I liked very much, medicine is an art based on science*.

Software Engineering could be the same art based on science. Hypothesis (i.e. scientific)-driven Validation in the form of TDD would therefore be required for the scientific part, the algorithms and processes. Empiric (i.e. psychological, social)-driven Validation would be required the arts part, the composition, experience and elegance. The latter would be hard to test, it would probably need to be monitored and replayed in simulations or regression-tests, at least documented, in order to be manifested for future generations of programmers. Clearly defining which part of a software system belongs into which domain might end many of the discussions, and bring back reason.

*) Apparently, this quotes originates from William Osler