The science of software ...

Back in 2002, I had my own form of Buccaneering.  As a developer on a UNIX aircraft project, I'd been in the buisness for over 5 years, and noticed a few parallels between some fundamental laws of physics and software engineering.

I'd written these up, and had them pinned on my desk as "The Talks Physical Laws Of Software Engineering".  Unfortunately I've lost all copies of them, so I'm recreating them from memory ... as you can see they're not comprehensive and were meant more for fun, and from a development over testing perspective.

But what they're an example of the concept of Buccaneering, taking a parallel idea from (in this case) physics, and bringing it into the software engineering context.  Of course none are particularly ground-breaking (although we were caught out by rule 6 at the time) ...

1)  Problems in code (defects) will remain, unless work is done on them [Newton's First Law Of Motion]  Really, defects just don't go away ...

2)  As you are doing work to remove defects, you are also doing work to potentially introduce new defects [Newton's Third Law of Motion]

3) Software that is developed without any monitoring will tend towards chaos [Second Law Of Thermodynamics]  You are just going to hope that everything is good?  Let me know how that works out for you ...

4) Small deviations applied over long enough distances cause massive errors [Trigonometry]  So try and find any defects early.

5) Any system will have levels of uncertainty [Heisenberg's Law of Uncertainty]  Of course you want to minimise uncertainty (which is part of what testing's about), but you cannot remove it altogether!  It will always be there in unknown finite levels.

6) The more closely you observe an event, the more likely you are to be impeding it [Heisenberg's Law of Uncertainty]  Coined as we learned that trying to rerun defects using a debugger could prevent the problems re-occuring - mainly as many debuggers of the time would initialise data stacks which would otherwise contain random data.


Maybe you've read these, and come up with a couple more examples in your head?  Congratulations!  You're thinking outside the box ...

Chicken Little and the Tester Who Cried "BUG!"

We all know the story of Chicken Little – he sees something fall from the sky (an acorn) and is so convinced the sky is falling in, he spreads panic around his friends, and they go off to seek the King, but end up getting eaten by a sly fox who uses the panic to lure them to their doom.

It's a sad fact but in the world of testing there are a fair few Chicken Littles.  And if you have one on your project, your developers in particular will get tired of them pretty quickly.

On a previous project with EcoEnergy we reviewed some designs for a website with development and marketing. And we got from marketing “oh no – this is a showstopper, the red is the wrong shade”. Looking around the table the developers were incredulous, but recovered assuring this was a minor change, and would easily be resolved.  But for them the bigger concern was the fact that all the data they were receiving from the back end was wrong, and thus they were misleading the customer.

With both the acorn falling from the tree and the wrong shade of red, not big issues. The acorn falling was actually a known feature of an acorn tree.  I know it's easy to mock the marketers, but although getting the look right for them is important to them (an application which looks ugly isn't going to lure people), at the same time as the developers were right to mention it's easily resolved, and not quite the sky-falling-in showstopper.

As testers it's our responsibility to inform management and developers when big bugs come along.  The kind of defect that jeopardise product delivery and timescales. So for instance, the misleading data which means we're liable for misinforming our customers, the system crashes etc.

Time plays a big factor too.  If our logo issue was discovered the day before go-live, it would be more critical.  But likewise if you get a serious bug weeks out from delivery, it's kind of the norm, and as long as it's defected and put on a path to resolution, it's nothing to get too worried about at that stage.

I figure as testers we're like the boy who cries wolf ... or should I say BUG! If we say BUG! too many times, eventually people are going to stop listening. I mentored a tester who escalated every defect she encountered the same way, even the cosmetic ones – eventually all her emails were being left in developers intrays, because they wouldn't / couldn't separate the urgent from the cosmetic

It's a bad place to be in, because a tester who's let that happen has lost the trust of her developers, and it's a very tough place then to be effective and win that back.  With the tester I mentored, I managed to steer her to rate her defects, and the really important ones she should really try and get the developer in to see what she'd experienced as soon as possible.  It became so much easier then for developer and tester to work together and solve the problems she was finding.

As I've said privately many times before, nothing really beats having a developer or business analyst on hand to ask “hey is this right” when what you're testing looks wrong.