Are you moving quality upstream? part 3

As I mentioned last time, if we want to move quality upstream, we need to change minds. Approach it from a people angle, not a coding one. Since that post, I have become infatuated with understanding approaches that encourage dev to have high bars for the quality of their code and not rely on test as a safety net.

Consider this quote from Alan Page:

I have a bit of a distaste for testing applications that are so buggy that finding bugs is like shooting fish in a barrel – bugs should be hard to find.

It’s those last few words that struck me. Bugs should be harder to find.  Isn’t that precisely what we are asking of Dev?  . Wouldn’t it be great if each of them pushed to make it harder and harder to find bugs after handoff?

Who should be recognized?

I decided I would go interview a few Dev friends on this topic. I asked them simply: Can you tell when a developer is choosing to move quality upstream and not rely on QA? If so, what behaviors show this?

The 2 most popular answers were:

  1. They are accountable for their quality. While this is not necessarily a behavior, it does mean if your actions show you are proud of the quality of your code, it does get noticed.
  2. They think about the tests before they code.*

*note: one friend mentioned that he was still trying to get folks to think through the design before they code. Frightening!

In some ways, the feedback is almost tautological. Clearly, there is not much further a dev can move quality than before he/she codes and certainly, if you are proud of the quality of your code, you are going to be self-motivated to keep pushing the quality up.

What can we change?

We can we make some changes to try influence teams to take on more and more of these behaviors.  Here are some of my thoughts for your team:

  • Training – Make sure your team knows what to do. Do they use Design Patterns? TDD? The Unit test framework? The Code Review toolset?
  • Train your Management – As example, Management, being business focused, often sees things like TDD as a downstream decision… something for the feature teams to make. In my experience, deferring quality is expensive, both in Time and Money. TDD means more features to our customers. Greater business value.
  • Scheduling: Get rid of your stabilization period and anything else that encourages bugs to flow downstream. Make sure time is added to schedules to account for code inspections and unit testing.
  • Reward Wholistic thinking – Discourage “right now is all that matters” or “we can fix it later” trains of thought. These are all versions of procrastination of quality. Instead, measure and reward those devs that are pushing to be done earlier. One simple idea to start might be to measure the time delta between when a bug got checked in initially to when it was found.
  • Reward Teams – use the power of peer pressure/social networks to encourage folks to work together toward quality.
  • Get Rid of Vanity Metrics – To move quality upstream, you need to “Get to Done”. Make sure *your* definition of Done isn’t only about “feeling good” about progress.
  • “Secret Shoppers” – I used to work for a grocery company in Southern California. They had anonymous random folks that would come in randomly to assess quality of the operation. Those reports would have a direct effect on a manager’s bonus. No Excuses. Why not do the same for your product? Couldn’t you have a group of random  senior testers in your company come in and evaluate quality of products at random intervals. You could do the same by having executives run through an important scenario periodicaly as well.

How about “Getting rid of Testers”?

I get this one asked a lot when I bring up this topic.    Often times, I think it’s a test to see if I can throw my beloved discipline under the bus if that achieves the goal faster/better.

I can.

Getting rid of Testers *may* very well be something that occurs, but it is neither a means to moving quality upstream, nor should it be a goal.   If you get rid of testers *before* you have moved quality upstream, you will add a huge amount of risk to your project and it will likely fail.

Why? Remember my Football helmet example?  Consider how would the NFL Players react if you got rid of their gear and they played without protection.   In the heat of the moment, do you think they would remember their predicament and avoid head to head tackles?  Or would they follow their muscle memory towards an inevitable pair of major concussions?

This is how I’ve seen it deployed in real life on engineering projects.  Teams go from a 1:1 dev:test ratio to a 5:1 ratio.   Far too often, what occurs is the dev team empathizes, “Wow, test is really screwed. I don’t see how *they* are going to keep up”.  They don’t see it as reason for them to change, so they don’t.