I don't have a problem with the people who fill these roles, and in fact one of my fondest memories as a manager was of the "QA" team at ShopWiki. I'll come back to that later.
It's a systemic thing. QA represents a safety-net for engineering. Coders who've been in-industry for any amount of time build up a habitual laziness with the quality of their code. They lean heavily on shitty terms like "code-complete", and "feature-complete." They don't talk about being done.
Let's talk about "done". First idea I want to murder with a meat-cleaver: "software is never done." Bullshit. Every version of my software is "done". It doesn't have every feature in it that I want, and it has bugs, but it's done. Most people think "done" means there's nothing left to do. I don't. I think "done" means that I've executed something fully. Explain? Ok: it means that what is there, works, to the best of my ability and knowledge.
I want to take on another platitude: "programmers can't test their own code because they're not objective enough." A former manager of mine, when we were discussing these concepts together, asked me: when you're working on a freelance project (I'd just gotten done a summer building iPhone and BlackBerry apps for hire), how is it that you were able to release (relatively) bug-free software at the end of the day? The answer is that I had to, because my paycheck depended on it, so I did.
Ok, so we need to get things "done", and I call bullshit on programmers not being able to accomplish this on their own. But that doesn't mean it's easy. Here are some tricks I use to approximate "done"-ness in my own output.
- I ask myself what I viscerally fear my client / boss / business partner is going to do with my software. You know the answer: it's that nag in the back of your mind about that hack you used to work around a bad design decision, or it's that you know there was a big 'TODO:' somewhere about validating form inputs for a page somewhere. Confront it, fix it, until you're not scared at all.
- spend time being your user. At GameChanger, we build our website and iPhone app on the same APIs that our partners will use. We go to little league games regularly and try to score them with our software, in real conditions.
- limit your scope. I want this on my gravestone (right after "loving husband & father"). Do only a few things, but do them right. And don't move on until you either drop a feature from the current scope or you would bet your career on it.
- figure out what you live or die on. For us at GameChanger, it's intuitiveness and ease of use. For the app I wrote for BlackBook magazine, it was sexy UI. Don't compromise here. Particularly powerful trick: never allow regression in your core feature.
- make engineers take full responsibility for their quality. There's no substitute for being on the line personally for what goes in front of your customers.
So no "QA" for me. I am willing to hire smart semi-technical people to do other stuff, though. The team I mentioned above functioned more like triage than QA- they hunted for problems, reacted to user feedback and researched root causes to help Engineering out, and often performed more research than testing. I was proud of what that team did, and I think they added a lot of value to the organization.
I've still got a lot to think about, and would love some more ideas on how to build this kind of quality-centric engineering into an organization while still adhering to loose process (agile, lean, continuous deployment, cool stuff like that). Any and all comments welcome / appreciated.
Posts
