Using Metaphors to Drive Business - Part 2, the 200-Point Inspection Metaphor

MAR 14, 2017 • Written by Wendy Closson

In my last blog post, Using Metaphors to Drive Business - Part 1, I explained why metaphors are so important and how they can help raise our chops (and our hopes) when it comes to influencing the business side of things.

The Seat Belt metaphor used in my previous example may have worked great for some, but not for others. Keeping a few different metaphors at the ready helps you adapt on the fly and better connect with the person you’re addressing.

Another one of my favorite car metaphors to use is inspections.

The 200-Point Inspection

Why?

The why remains the same. The goal for all of these metaphors is to provide examples that are relatable.

  • Communicate current test coverage to business without using a percentage.
  • Get business to push for test coverage instead of against.
  • Create team unity and process around test coverage.
  • Resist reactionary decisions based on internal and external drivers that interfere with test coverage.

The Metaphor

We’re back in that car. But we’re no longer focusing on the seat belt.

Imagine yourself in the vehicle. Now, think of the check engine light or the passenger door ajar notifiers as test output.

These systems are in place to let you know when something needs attention. Without these warning lights or sounds, you could never be sure that your vehicle is safe to drive. Would you drive your children and their friends to soccer practice without being certain the vehicle is safe? Unlikely. So the only way to be certain that your precious passengers – and yourself – were being transported without risk would be to check everything every time you drove your car. That means, you would need to perform a 200-point inspection every single time you went anywhere: work, the gas station, the store.

Imagine how frustrated you would be if you had to do your 200-point inspection every time you ran out of milk?

It would seem reasonable to save time and only make sure you have enough gas to get there. The store is only a block away. What could go wrong? Famous last words, right?

And just like in everyday life, in the software development world, plenty can go wrong. The interconnected nature of development creates a ripple effect with every change. This means a simple issue with the wiper fluid can take down the engine.

Even if this never happens, over time your car will degrade – or worse – you’ll get stuck on the side of the road during a rainstorm, with a dead cell phone and an ill passenger.

If you’re like most people, the problem wasn’t even on your radar. Sure, maybe you knew the car was a bit past needing an oil change, but did you have any idea the engine was blown? The consequences can be severe. And you will have a very difficult and expensive choice: rebuild the engine or replace the car completely.

Let’s say you were disciplined enough to keep up with inspections, what happens in an emergency? Say your child wakes up in the middle of the night with a fever so high they must be rushed to the hospital. Too tired and stressed, there is no way you are going to check anything. You are left with a Hail Mary and high hope that you weren’t lazy the last time you noticed the fuel tank was low.

Life is filled with late-night, unexpected trips to the hospital. No business wants to be driving a car that needs a 200-point inspection every time before hopping in.

This is why automated test suites are critical. The warning light in a car works like an automated test suite by constantly monitoring and providing warning when necessary. Just like an unchecked light in a car could spell disaster, not using automated test suites in systems could allow issues to compound leading to a potential systems’ crash.

Remember the Purpose

I mentioned this last time, and it merits repeating: although these metaphors seem silly to you, they are not for your benefit. They are for the business folks.

Don’t be mistaken, though. I’m not saying you need to dumb things down for them. It’s simply that their speciality – or technical knowledge – is in a different field. Keep that in mind as you go through your chosen metaphor.