No Black Swans Or Always Expect the Unexpected

So, I expect many, if not most reading this, have heard of Taleb's Black Swan theory.  He put this forward around those things that people write off as being so far in the extreme, or so improbable, that "no one" could predict them.  Many folks far more learned than I have discussed this many times over.  Not just around software events, but in disasters, both natural and, well, not so natural.

Fact is, I have seen so many things in software testing that other folks would write off as "improbable" or "unrealistic" or simply snort in derision over.  There was the developer who once tried to say "No user would ever run this purge process with nothing to purge."  Really?  Never?  They'd always know better because, well, they'd know never to do that?  How would they know?

I can also think of the times I walked into the same trap, unwittingly.  I learned.  I learned to be aware that I can not anticipate everything.  Now, sometimes that seems odd.  Then again, when I think about it, I ran into the same kind of problems other folks had, like those for whom a test result, or worse, an actual event, in production or in the wider world.  That problem was, and sometimes still is, perception.

My way of thinking, approaching problems or questions, is sometimes self-limiting.  The fact is, I suspect it is the same for most people.  What I believe, or maybe hope, is that my awareness of this can help me work around it and be open to multiple possibilities. 

Hmmm - that sounds kinda wishy-washy.

What I mean is that I try and be open to the possibility that I missed something.  Usually when I do miss something, its because of my own perceptions, my way of approaching a question or scenario.  Broadly, my frames. 

These models of thought can be usefull.  If we are not aware of potential limitations, we will find ourselves in the "No user would ever do X" camp.

Now then.  Something REALLY unexpected?

My lady-wife keeps a large garden.  We also capture rain water in a couple of large barrels to water that garden.  Sometimes, when there is a lot of rain, we will line up some buckets and catch extra water from the run-off of the car-port roof. 

An interesting thing happened last week.  The lady-wife was trimming some plants.  One of the branches had some nice looking flowers on.  She decided to put it in a rain-filled bucket until she could bring the flowers in the house.  She looked in the first bucket in line and saw a small fish. 

A FISH! 

Just a small little guppy looking thing.  No.  We did not put it there.  We have no idea how it got there, although we've bounced around some fun theories.  Have we come up with a model for how it got there?  Sure.  Several.  We don't know which, if any, is correct.

So a fish in the rain bucket is something I definitely did not expect. 

Maybe I should have.

Gardening

We have a fairly large garden. Actually, my lady-wife has a large garden and I'm the helper. This works out pretty well for both of us. She gets more work done than she could do herself, and I get something interesting that can sometimes be missing when working in some software shops: a specific, tangible result from your efforts.

In some places I've worked, projects are never really "done." You finish one project and the next is, well, more modifications to the same application. The result is, you are never really "done."

Gardening isn't like that. You work for four or five, or more, hours in a day and you can see what you have accomplished. You can see clearly defined areas without weeds, flowers, maybe vegetables, but always something you can look at and say "I did that today."

This weekend was a great example. Saturday morning there were some big, ugly nasty weeds growing along the fenceline, near where the vegetable garden goes. We got well over half of the weeds dug or pulled. By the time we had made it that far, the sun was pretty hot, so work shifted to a shady area in another part of the year. While we did not finish that portion on Saturday, the work that remains can be finished in another good day's work. The list is fairly simple: finish pulling the weeds; till the garden; hoe it back into rows. Then we can plant again.

Last year's rows are still visible. This is part of the garden's version of a "legacy" system. The footprint of last year is there. The problem is, sometimes that can make more work.

Where we are, and a fair portion of the state and region, tomatoes had a blight last year. This was a fungal infection, related to the same blight that caused the potato famine in Ireland in the 1840's. The relationship is the spores from the fungus. Because the spores are found where the plants were last year, there is a problem with the "legacy system" - we can't put the tomatoes where we have in the past. We also need to get them as far away from where they had been as we can get them.

The solution was pretty simple. Spores are contained in the ground. To keep the tomatoes from getting blight keep them from coming in contact with the spores. So, as with most of the really good ideas in the garden - well, all of them, my lady-wife came up with a solution. Pots. Lots of pots. Large pots. Lots of very large pots. In a sunny spot with no contact with the soil that may have blight spores. The top of the driveway, of course. Hot and sunny, good for tomatoes. Near the rain barrels so easy watering. Tomatoes like a lot of water, so this is good for both them and us.

Moral of the story? Just because you've "always done things this way," does not mean that another is available - particularly if the solution presents itself.

Have you ever noticed that the solution "presenting itself" usually happens when you need to completely change the rules? How often can we make the rules change in what we do with software? Beets me. Lettuce try.