Lessons from Math - I

Yesterday, I suggested a topic of "Testing Lessons from Mathematics."

Yet in my recent work, I'm becoming much more holistic about software.

If I find a particularly interesting point that applies to requirements, do I throw it out? Probably not, so, I've re-titled the series. I will call it lessons from math and we'll see where it leads.

Math, like most other disciplines, has it's own lingo; please forgive me for introducing new words, but I'm afriad I will have to in order to advance the discussion.

Today I would like to talk about two math lingo words: Prima Facia Evidence, and Axiomatic Evidence.

Prima Facie evidence means a statement that is true on it's face. Something like 1+1=2 is taken in math as Prima Facie. The idea that when we are building software for someone else, that person should describe what we are building before we build it is prima facie - it just seems obvious.

An Axiom is a little bit different. Axioms are the basis for formal systems. It may not be obvious that these things are true, but we assume they are true for the purpose of working in the system. For example, Euclid assumes that two parallel lines never intersect. You may remember from high school that Euclid doesn't actually ever prove this, and neither does anyone else. Yet there is an incedibly large amount of higher geometry based on this, and it seems to work for constructing bridges and so on.

Now, Wikipedia and I disgree a bit on these two terms. According to wikipedia, Prima Facie is evidence in a legal sense, while an Axiom is a logic that is self-evident.

Now, here's the trick:

In higher math, you do a lot of proofs. Lots. There are several ways to solve them, but the simplest is proof by deduction. To do this, you express an idea, then simplify and simplify that idea until you reach an axiom, and stop. Basically, with proof by deduction, you say "If this axiom holds true, then my assertion must be true."

Example: X^2+4X = - 4
If that is true, then this is also true: X^2+4X+4 = 0
If that is true, then this is also true: (X+2)(X+2) = 0
We know that one of those X+2's must be zero, becase the only number times another number that is zero is zero
So X+2 = 0
So X=-2

Yet each step in the process required a transformation that is an axiom. "You can subtract a number from both sides of the equation and it is still true", for example, is an axiom.

It turns out that you can find lots and lots of interesting things by assuming the axiom is not true and working backwards. If you find a contradiction, that reinforces the idea that the axiom is true.

But, sometimes, you DON'T find a contradiction. For example, what would the world be like if parallel lines did intersect?

There is an entire school of math based on this called non-euclidean geometry. It isn't even a rat-hole; it turns out that parallel lines DO intersect on the surface of a sphere - at the poles. And this is really helpful for mapping, say, for example, the world we live in.

So what am I saying here? There is a difference between ideas that are prima facie (flippin' obvious) and axiomatic - things that we have to assume are obvious in order to build.

A great deal of the software testing world believes that if we sacrifice everything to the world of repeatability, we will be successful. In the factory school and the CMMI, repeatability is held up as the goal.

That's not prima facie. It's axiomatic. And, while we can build very large castles in the sky by assuming repeatability is the key goal, there is another way to grow: Ask ourselves what we could do if repeatability was not the goal.

Non-euclidean geometry is cool, sure. But I'm more interested in changing repeatability in testing from the express goal to sacrifice all effort to.

I submit that the real goal in software testing is to provide accurate information to decision makers about the software under evaluation - as quickly as possible.

In that case, repeatability is different - it is something that might be helpful for some of the time.

That allows us to branch out with different techniques that are not repeatable, but just might be reliable.

More to come.

--heusser
(*) - Thanks, Sean, for starting me down this road.