Management It's better than a poke in the nose

Healthy Tension

As a manager in any software engineering organization, you’re going to be subject to a lot of interpersonal angst amongst the team members. You’ll be walking to lunch and Engineer A is going to be ranting and raving about Engineer B on another team…

“Man that guy bugs me. Have you seen his code? Wow! Unreadable. Totally incoherent. ”

9 times out of 10 if you put Engineer A and Engineer B in the same room, you’d be unable to discern that there was an actual issue because they’d treat each other professionally and with courtesy.

Fact is, the angst was faux angst and while there may be an issue there, your primary job was to sit there and be a sounding board. The issue will often resolve itself or just be that… an issue. Where you’re going to need to get involved is where the angst is real and potent and, well, as emotionally charged as I’ve ever seen in hi-tech… the bug database.

Repeating for clarity: A bug database is where people truly develop hate in software engineering organization.

It’s always during the last few weeks of the development when the bugs become the one and only metric the organization is watching to see if the product is going to ship. QA knows this. Engineering knows this. Their days are centered around reloading database queries which show them how many bugs are currently on their plate. More is bad, less is good. Zero is best.

The reason the hate erupts between QA and Engineering is because most software engineering organizations create a healthy tension between QA and Engineering. The tension is based on a simple idea:

  • Engineers create code which makes a product.
  • QA confirms the code is written well (which it often is not).

These are contradictory goals. Let’s simplify them into declarative statements:

Engineering: We believe we have done our job.

QA: Uh, no you’ve haven’t.

Of course Engineering is going to want to give QA a poke in the nose. QA is telling Engineering they’ve done their job poorly and what wants to admit they screwed up?

For much of the cycle, everyone is so busy designing and developing the product that not much attention gets paid to the bug database. That changes as soon as a graph gets posted on someone’s door which shows the bug arrival rate versus the bug fix rate. The race is on… who is going to win? More fixes or more bugs?

The bug database becomes the plan of record for product and all hell breaks loose because, well, everyone is trying to do their job and it turns out the bug database is the last place they should do it.

If you’ve spent time in a bug database, you know the precise emotion I’m talking about. Read this bug report and reflect:

Bug #52392 – App crashes (Severity 1)

Steps to Reproduce:

1) Click on the application (Build #45)

2) Application crashes

Expected Result:

The application should not crash

Let’s assume this is the first bug report you’ve ever received from this QA person. You’re going to cut them some slack, you respond with:

Engineering: Thanks for the report. Could you reproduce this and send me a crash log?

Three hours later and you receive the bug back with the following information:

QA: Just click on the application and you’ll see this for yourself.

Grrrrrrrrrr. Ok, now your pissed. Who is this boob? Doesn’t he/she realize that if the application DIDN’T EVEN RUN that it would have never even gotten out the build team? And even if it did, every single engineer on your floor would be bitching and moaning about a broken build. WHAT A DUMB ASS.

Can you feel it? The blind rage over a text entry in a database? Boy, are you tense. Take a break and let’s see what happened.

See, the data you need in this bug wasn’t in the steps to reproduce. The data was in a subsection of the bug that you never look at. This tester is a wireless tester and it turns out your application does crash in a wireless set-up and he’s the only who does wireless testing in the building.

Why in the world do you want to hate this guy? Just because he’s doing his job? No… you want this guy beaten because it appears from the bug report that he’s an arrogant twit, but the fact of the matter is, you’re a lazy bug reader.

This is one of a million unfortunate situations that happens in late in a product cycle. Yes, there are truly twits out there (in both QA and Engineering) that should be poked in the nose. Still, when I’m forced to triage the aftermath of a bug war, it’s almost always individuals trying to resolve conflict via a bug rather than getting their butt out of their seat, walking over to the other individual involved, and acting like a human being.

Anyone who has had significant experience interacting with other people via email, instant messaging, IRC… whatever… you know that context is lost when you translate to text. You know that when you really want to understand what someone is trying to say in email, you pick up the phone and ask, “Um, what the hell are you talking about?”

Yes, the healthy tension must exist between QA and Engineer because they do have conflicting goals. Your job as an engineering manager who doesn’t want their team poking each other in the nose is to remind your team that, first, if you’re grinding your teeth in your office as you’re reading a bug, I guarantee, I promise, I swear that you are missing some essential piece of revealing data that is just short walk away. Second, both teams, QA and Engineering, have the same goal. They must ship product.

#

8 Responses

  1. Buzz Andersen 20 years ago

    Any proper QA person (as opposed to just some random person in the company who happened to be living on the software) who filed a bug about a crash without attaching a crash log or any additional description definitely deserves whatever derision they get. That said, I know very few proper QA people at my company (same as your company) who would :-).

  2. Eric 20 years ago

    The thing I hate is when testers file a bug that says “When I do steps 1 – 37, I get an error dialog.” I end up spending a couple of hours whittling down the bug only to find out that all you need to repro it are steps 36 and 37.

    I know in some cases the testers are trying to be complete, but I also know certain testers whom are either lazy or to whom just don’t think to search for a root cause.

  3. Alex 20 years ago

    I spent alot of time looking at these tensions and one day it hit me :

    I went with my aunt to a doctor, while we there she told the doctor her hip was really painful, to which he replied “it’s probably nothing”, when she asked if he could take a look, a xray or something he replied : “you know miss I studied medecine 7 years, I think I know what am talking about”

    Then I just thought, maybe this qa/engineering tension is just some inferiority complex. You know when you look at your average software tester, it’s a guy who earn a quarter of what a engineer makes, doesn’t own a degree or is studying, not someone a bachelor of science would respect in any ways. I still believe that is source of much tension, you can’t receive a critic from someone you don’t respect. I still haven’t find a way to fix it, on the next project I asked to hire only retired teachers with computer skills, you know peoples who have a lifetime experience of dealing with arrogant pricks. I’ll see how it goes.

  4. Craig 20 years ago
  5. Mark Eichin 20 years ago

    I’ll agree that QA’s goal is *not* to ship product. QA’s first goal is “to make sure we’re shipping what we say we’re shipping” and second “to make sure it isn’t embarassing”. The latter is where the “my goal is not to ship” bit comes from, really – finding a show-stopper (or “heinous”) bug is a success because you’ve prevented an embarassment, not because you stopped the show. This leads to a demand for QA automation that can be run as early as possible in the process so things get noticed sooner when fixes are cheaper.

    (And it is a demand – I’m primarily a product and systems engineer, and while I’ve built our QA automation up fairly far, we really need a full time QA automation lead to take over – but just like everyone who can “code” HTML thinks themselves a developer, every “tester” thinks themselves a QA specialist. I can find developers by networking, though – I don’t have the contacts and sanity checks on the QA side, so it is a lot harder.)

  6. Skiurlaub 20 years ago

    Great Website! It helps me a lot with my stuff World Q- homework. I’m not so hot in that class. Thanks for the hard work, keep it up!

  7. anonymous email 19 years ago

    There are not many good QA people because this job kind of “sucks” Before they get mature enough most of them quite their jobs. You can get a better career with sales.

  8. silvermine 18 years ago

    Wow. I must be weird. I’m the engineer who begged for a better staffed QA team. You see, I don’t get upset when they log a bug, because they just saved me from another opportunity to look like an idiot in front of my customer. They might think I’m an idiot or not for my bug, but it’s better them then someone outside the organization!