Are you moving quality upstream? Part 1

I hate the cliché “Move Quality Upstream”. I mean it. I detest it.

Those words have justified changes in staffing, automation strategy, process changes, milestone dates, etc. The end result: More of the things that changed, but the product still falls apart at the same places. Long stabilization milestones are still needed. All that work to move quality upstream and it gets flushed back down. Code velocity probably increased and the cost of doing business certainly increased, but did quality move even an iota forward?   The phrase tells us what to do, but not how to do it or how to know we acheived it.   It’s inactionable.


The NFL has had similar problems. They have been improving helmet technology for years, but concussion rates have kept pace. One study I read recently  –  but not so recently that I can find it again… Grrr! – mentioned that the improvement in the helmet tech might just be the cause.

Basically, how it works:

  •          NFL players are incented to hit hard ($$, glory, competitive nature, etc.)
  •          The better helmets function, the more confidence the player has in safety
  •          The more the player believes he’s safe, the riskier behavior he takes on
  •          the riskier behavior he takes, the higher the chance of injury

I was watching the 49er’s pummel the Seahawks the other day (Go Niners!) and the referee called a penalty against one of the players. The tackler had initiated a helmet to helmet tackle and this is now a NO-NO in the NFL. The announcer mentioned “the referees were all asked to call the penalty even *if* they weren’t 100% sure”.

Will this fix the problem?  Maybe.   I think it could help.  This shows that the NFL is viewing these concussions as a behavior problem of the player and not a failure of the equipment.  The penalty is one of the worst in the game.  However, the powerful incentives still exist in the game and penalties happen all of the time.  How often will it be the cause of a loss?  Probably rare.

Ok, Brent.  Neat story, but…

“What does this have to do with Testing?” you ask.    As I mentioned last time, Testing minimizes risk “of injury”.  Far too often, we are the ever-improving Helmet and our development team plays the part of the NFL player.  The more we improve, the more dev trusts the safety net we’ve provided, the faster dev goes…

But not better.   Instead of moving quality upstream, we’ve made the stream faster.

I’ll go into what to do about it next time.


5 thoughts on “Are you moving quality upstream? Part 1

  1. Rob Lambert had a post about the Peltzman Effect “The Peltzman effect is the hypothesized tendency of people to react to a safety regulation by increasing other risky behavior, offsetting some or all of the benefit of the regulation” and I risk homeostasis – so I’m looking forward to your next post where you talk about how to deal with this 🙂

    • Yikes! Did I just claim I can solve something that armies of psychologists are still theorizing over? Well, you and I both are looking forward to the next post.

      For now, I’m going to focus Moving Quality Upstream and it very well may morph more into Risk. I am heavily ruminating over the idea of Risk Homeostasis. At a basic level, it seems to describe that the total Risk of a system stays constant. It doesn’t feel true to me as yet, but if it is, maybe the trick of it will be to think of it like the bubble in a leveling device. Can I put the risk exactly where I want it? Or can I shake up the level and make it less concentrated? (a thousand paper cuts might be better than 1 bug concussion) <== That was a spelling error. I meant 'big', but I like the idea of a Bug Concussion. =)

      I'm going to look at getting Wilde’s book (free when work pays for it)

      THANK YOU SO MUCH for the links. I had not heard of either of those terms. I’m sure they will have non-trivial influence over my next post. I really enjoyed reading the sites and several of the linked sites.
      One thing that I am really enjoying about the blogosphere is the collaboration effect on topics. Several testers have come to the same conclusions I have and are working on the problem. (hopefully, it’s a solveable one). I currently think it is and that Behavioral Economics can point us in the right direction (Wilde and Gladwell seem to be Guru’s on the topic and I would add Ariely and Levitt to the list. )

      Currently, I’m looking around looking for a way to deep dive more into that topic. Seems it’s a relatively new field here in Washington state, but I suspect readily taught in your part of the world.

  2. I like the concept of moving quality upstream, but I believe that it often fails because it usually puts quality in the hands of people who are not as invested in quality and who are not rewarded for high quality. If teams reward developers for more features, rather than quality, then they’re not really trying to drive quality up stream.

    One thing I noticed recently is that as teams tried to move quality up stream, they did not spend as much time moving the quality gates up stream. Static code analysis tools have been around a while, and automation is easy to run on code before it’s in the product, but those have been around for a while. I haven’t seen any huge jumps in static code analysis recently. In fact, I haven’t heard of many teams or people doing much root cause analysis recently (which gives me an idea of things to look into…). If we’re going to move quality up stream, the quality gates need to move upstream and get better.

  3. Pingback: Forgive me, father, for I have sinned. | Testastic

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s