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
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.