Irrefutability

Irrefutability

I found myself inspired, early this morning, to formulate a potentially novel criterion for the presence of “engineering” in software, namely, “irrefutability”. I think that “irrefutability” might be a good proxy for “engineering” because it seems to me that “engineered works” become “engineering failures” (i.e. representatives of a discernable class of failure rather than isolated instances of incoherent failure) precisely when the justifications of their “constituent decisions” become refutable.

Take, for example, the ever-popular Tacoma Narrows Bridge story. Is it not the case that engineering grew as a discipline when the bridge collapsed primarily in that engineers learned how to retrospectively refute the sufficiency of the bridge’s design for the environmental conditions present in the Sound?

Notes

My thinking at the time was somewhat influenced by three proximate causes:

• reading the first few chapters of Scott Rosenberg’s Dreaming in Code,
• discussing an MSDN article that I dug up on the subject with Bernie and Chris, and
• reflecting on the TOCTTOU races which POSIX forces onto userland programmers.

but also, perhaps most strongly, by Benjamin Pierce’s delightful chapter epigraph:

A proof is a repeatable experiment in persuasion. - Jim Horning

Comments

1. Bernie writes:

    You imply that an unproved design choice corresponds to a design flaw,
    yet it's often the case that stuff that instinctively seems to work
    happens to work also in practice.  If we start asking engineers to make
    their designs bullet proof, then we rule out a lot of good designs that
    happen to be hard to prove right. Most people are content with a bunch
    of automated tests these days :-)

   I might reply, point by point:

   1. “You imply that an unproved design choice corresponds to a design flaw…”

      No, I’m only arguing that every design flaw corresponds to a refutable design choice, not the converse.

      (I’m actually making a slightly stronger statement; namely, that we begin to recognize design choices as design flaws precisely when our experience starts to refute them.)

   2. “…yet it's often the case that stuff that instinctively seems to work happens to work also in practice.”

      Sure. All this says is that it’s possible to make good choices without being able to fully justify why they are good.

      More strongly: these “unproved design choices” are not engineering; they are guesses. (Perhaps even very good ones, backed up by years of experience, but guesses nonetheless.) What fascinates me about them is that so few “software engineers” recognize (let alone remark on) how many significant guesses they have to make in order to accomplish their work.

   3. “If we start asking engineers to make their designs bullet proof, then we rule out a lot of good designs that happen to be hard to prove right.”

      So perhaps we should ask for a lesser thing – for our “engineers” to distinguish the decisions which they can persuasively argue from the ones which are (hopefully) inspired guesses.

   4. “Most people are content with a bunch of automated tests these days :-)”

      Yes, most people are not engineers.

      (This is not to discount the value of a good automated test suite; merely to argue that most interesting problems are expensive to test automatically.)