Sub Standard Strategy

Today I'm going to be telling you my first job in IT, and how it not only shaped my way of approaching problems, but should yours as well ...

It was hard for me to get my entry into IT. I was a bit of an odd penny, I'd learned a lot from books about programming, but really I was more a mathematician and applied physicist.  Hence my odd-shaped background found an odd-shaped opportunity - that of a mathematical modeller for a navy sonar simulator.

So what does a mathematical modeller do?  I had to create working continuous programmable constructs (ie "models") of various ships and submarines from around the world.  These models would be used in a simulator in navy training to train crewmen in identifying different vessels from how they looked, sounded and moved, and hence had to be as close to the original as possible.

For friendly vessels it was pretty easy - we'd have all the information we'd need, and it was never too much trouble.  For vessels from other countries it was more challenging, and consequently more fun.

I'd receive an assignment from our customer, which would provide a summary of all the information we had on it - including any snapshots of what it sounded at at different speeds.  I would be tasked to build a model that could reproduce this as best I could.  Needless to say this was pretty secret, and I worked in a secure environment.  Whilst this wasn't quite Tom Clancy, we weren't allowed the internet (though it was pretty primitive in those days), there were code keys on all the rooms  and we kept our hard disks locked in a safe each night (in all I had about a dozen door codes, passwords, and safe combinations I had to memorise).

Thankfully though the data was secret, our methods were much more familiar to any data scientist today.  We used the information we had, we looked through publications like Janes Fighting Ships ships to fill in some extra, and then we'd look at all the things we didn't know.  Typically what we didn't know far outweighed what we did - and it's not like you can phone the relevant government and ask.

To get more into the mindset of what I was doing, I read everything on surface and submarine history warfare that I could.  I needed to understand the vehicle I modelled, not as a series of numbers, but as a working machine, with different parts and components - understanding how it operated, and how it all came together.

Understanding the kind of vessel, the period, the manufacturer helped a lot.  I would look either for other vessels which we'd modelled before which shared similar characteristics, or if need be, one of our own vessels which we had better data for.

All the time we build up a document which showed our assumptions, why we'd chosen X over Y.  Submarine A had a similar engine to submarine B, so we copied some figures.  Ship X had a similar weight and shape to ship Y, so we copied some details on maneuverability.

All the time we were running our model through our simulator - being sure it didn't break or act weird.  But most importantly it operated as expected for those few points of data we did have.

Sometimes though all this wasn't enough - the secrecy of our work caused issues.  It's not like we could just send an email, letter or even just pick up the phone - and our customer and their experts were 100 miles away.  Hence we'd try and book meeting to get them down, or for us to go to them - we'd work through our assumptions, to make sure they were comfortable with what we were doing, and ask for directions when we were completely blind-sided.  As well as put what we did have through it's paces for them, to ensure they were happy (we were fortunate to be able to make tweaks as we went, recording our decisions though).

It was challenging - like solving a complex puzzle.  But it was fun.


Strategy For Testing

Flash-forward to today, and a lot of that fun of the chase still occurs in my career, but in the test strategy and estimation game.

A lot of the steps there still apply.  As testers we can become frozen to stone over "those things that we don't know".  Typically upfront at the start of the project, or when you're bidding, much like with my mathematical model, there's so much more unknown than know.

To me, my approach, and suggestion to you is pretty simple - and it follows the above rules.  The Golden Rule is obviously "show your working", make clear why you're putting forward what you're putting forward.

• Show what you know and can work out.
• Show what's not clear but feels familiar and illuminate it as such, "but for similar projects, we've used xxx"
• Show what you're really uncertain of.  If need be take a guess, and record it as such.  But try to get a meeting with someone who might know more - even if it means pumping your network for guidance (this is why a network can be helpful).  However like me, be aware your material might be confidential, so you might need to be careful how you ask.

What you've actually done doing that is weaves a story of the risk of your project and some of the unknowns.  Something useful to share with your team and your project manager, and hopefully either accept the risk, or get more feedback to remove some of the uncertainty.

Out of interest - a year after I left this role, I looked up the first submarine I ever modelled (which I obviously can't name).  Of the fleet, two had been sold into scrap.  The remaining sub now serves as a museum and gift shop ... typical!