Sunday, March 15, 2020

Getting Myself Koen

Much of Definition of The Engineering Method by Billy Vaughn Koen chimes with what I've come to believe about testing. 

In part, I think, this is because thinkers who have influenced my thinking were themselves influenced by Koen's thoughts. In part, also, it's because some of my self-learned experience of testing is prefigured in the article. In part, finally, it's because I'm reading it through biased lenses, wanting to find positive analogy to something I care about. 

I recognise that this last one is dangerous. As Richard Feynman said in Surely You're Joking, Mr. Feynman!: "I could find a way of making up an analog with any subject ... I don’t consider such analogs meaningful.” 

This is a short series of posts which will take an aspect of Definition of The Engineering Method that I found interesting and explore why, taking care not to over-analogise.

So I finally got a copy of Definition of the Engineering Method by Billy Vaughn Koen. It's probably only ten years since I first came across it in the AST's Black Box Software Testing, or perhaps Rapid Software Testing, or maybe both.

I'll review it later but right now I want to note something that I love. No, two things.

First, Koen on the engineering method's reliance on heuristics contrasted with the strictly logical underpinning of science (p. 14, 20-2):
... if the system you want to change is complex and poorly understood; if the change you will accept must be the best available; and if it is constrained by limited resources, then you are in the presence of an engineering problem


Unlike scientific laws, heuristics have never taken kindly to the harness of conventional logic systems ... Science is based on conflict, criticism or critical thought ... a new scientific theory, say B', replaces an old one, B, after a series of confrontations in which it is able to show that — as an approximation to reality — it is either broader in scope or simpler in form.


One heuristic does not replace another by confrontation but by doing a better job in a given context. Both the engineer and Michelangelo "criticise by creation, not by finding fault."

Second, listening to a recent episode of In Our Time on Paul Dirac, who won a Nobel prize for his theories of quantum mechanics, where one of the experts on Dirac said:
He could do something that mathematicians considered not quite right. There was something called the Dirac Delta Function that he introduced [which is] not a function even though he called it one and mathematicians worried about it for years ... I think this is where the engineering side comes in; if it worked and did what he wanted it to do he didn't worry whether it had ... the blessing of pure mathematicians.

So he had this fantastic mix of having exquisite mathematical knowledge and the pragmatism of saying "if it's not quite there but it works, I'll run with it."

Did I say two things? I meant three things. Koen's paper is amazing; the synchronicity of  hearing the ideas applied to Dirac while reading Koen is thrilling; and the connection to my long-term interest in combining theory and practice really gets me going.
Image: Amazon

Edit: I began reviewing Definition of the Engineering Method in Sota so Good.

No comments:

Post a Comment