Dwight D. Eisenhower said “In preparing for battle I have always found that plans are useless, but planning is indispensable.” After reading Jason Yip’s No matter how many times you say it, we still don’t need a QA on the team, I started thinking about how similar this is to the correlation between (software) quality and exploring what software quality is. In the spirit of Jason’s article, thinking about how you “get quality right” will have more positive results for the sake of quality than searching out defects. So the question stands, how do you get quality right? I’m not sure there’s a cut and dry answer, but I have a feeling it’s in the details. I know it sounds anecdotal, but quality isn’t easy. It requires a lot of effort applied constantly. It requires reward and incentive, not punishment and fear. It’s caring about small things, and shifting how your team thinks, communicates and works together.

Jason wisely points out, “Everyone has a responsibility for quality.” But how are you ever to translate this to your team that plays the blame game, avoids at all real issues of quality, or blindly assumes that the “QA” (sic) will find all the product defects? How do you start this discussion, much less keep it going constantly?

Do you simply say, “Quality is your responsibility”? Or hang a sign on the wall to the same effect? I wouldn’t. The very idea of it undermines the ideal you’re trying to espouse: taking personal responsibility. It does nothing to encourage people to care about quality, outside of fear of losing your respect, maybe.

It’s leading by example. If someone finds a defect in my work, or takes issue with something I’m responsible for, I congratulate them with a “Good catch – thanks!” It may sound silly. It may even sound sissy. That’s natural. After all, we’re brought up, educated, cultivated with instincts to defend our own work. I wouldn’t be the least bit surprised to learn the average adult brain is predisposed to think this way due to the way its been “wired” through learning, and even, more philosophically, through our own sense of ego and intellectual self-worth. But think about psychologically what “good catch” does instead:

1. It acknowledges your teammate’s effort, and encourages that person to continue to put forth the same effort. Or more.
2. It encourages me to be more diligent in the future, even if I don’t agree 100%.
3. Most importantly, it tells my teammate that I care about quality, too.

Yet, all of this assumes people on your team desire to produce quality software. Somehow I had to tie this into Programming: Love It or Leave It, right? More rambling to come on this topic later.

More Related Content

• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• August 2, 2008 -- How I Escape the “Reuse Trap” (0)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 24, 2009 -- The Elements of Reusable Code (0)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• January 21, 2009 -- 16 Apps That Lessen TEH SUCK of Web Development in XP (8)
• December 1, 2008 -- 24ways (1)
• March 19, 2008 -- New Wave Logging (0)