On Software Quality
by Chris Wash on Jan.13, 2009, under Software Engineering
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:
- It acknowledges your teammate’s effort, and encourages that person to continue to put forth the same effort. Or more.
- It encourages me to be more diligent in the future, even if I don’t agree 100%.
- 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
Leave a comment
-
Welcome to cwash into software!
This is a blog by Chris Wash about software craftsmanship. The views and opinions expressed here (for better or worse) are my own. Thanks for stopping by; be sure to let me know if you have any feedback! Feel free to leave a comment here, contact me or subscribe to the RSS feed.
Who Am I?
Chris Wash is a software developer and tech geek extraordinaire in Richmond, VA.Where Am I?
Stack Overflow
January 13th, 2009 on 11:06 pm
Good post, man; couldn’t agree more that “everyone has a responsibility for quality”.
Seems to me the challenge is getting team members who either aren’t aware of that responsibility, don’t accept it, or don’t care – to buy into the concept.
January 14th, 2009 on 3:45 am
Yeah.
If you aren’t aware, that’s relatively easy to deal with. If you don’t accept it or don’t care, aye, there’s the rub. Much harder.
That’s when the lead by example comes in. You just aren’t going to be able to inspire everybody individually. I think, if there is an answer, it has to get back to incrementally trying to improve and grow as team. Becoming the team that attracts good players (not buys them – think Devil Rays, not Yankees).
January 14th, 2009 on 3:47 am
Excuse, me, “Rays.” Anyway thanks for the comment.
January 21st, 2009 on 11:32 am
Read this blog just after reading another blog with the title “Genuinely surprised when software fails?”
http://testmuse.spaces.live.com/blog/cns!FCF2D51D333DA1FD!355.entry
In it the author shows off his big red button from the 80’s “TEST then CODE” and relates a tale about how a dev would bet him a dinner that he couldn’t find a bug in his code. Mutual respect and improvement – just like you saying “Good catch”
January 21st, 2009 on 5:35 pm
Great point, Phil. Excellent example, right on – it’s the little things that foster the attitude needed to produce a quality product.
An outsider might consider it arrogance or competitiveness, at first glance, but we understand that’s not what it’s about.
January 24th, 2009 on 11:23 pm
I would tend to avoid “Everyone has a responsibility for quality” as a standalone phrase because, as you suggest, it doesn’t really lead to knowing what to do next. Instead if we think about how together we are are trying to design a system that has built-in-quality then whenever that system fails, it goes even beyond “Good catch – thanks!” to “Why did that happen?” and subsequent adjustment of how we do things.
January 26th, 2009 on 12:35 pm
@Jason – Agreed. Again, I think it’s in the small stuff that counts here. It requires constant focus and attention to detail from not just a single person but everybody. There really isn’t a great way to get to that without getting the team ‘culture’ right.
January 27th, 2009 on 9:54 am
I agree with Jason’s comment if you think of “Everyone has a responsibility for quality” as a slogan, but whoever defines roles for the team (usually the PM but I like it to be a team activity) needs to make sure responsibility for quality is built into each role. For example, the team should define what a good requirement is and then not accept the requirements document until all of the requirements are good. Coders shouldn’t promote from development until their code works. These really sound obvious but I’ve seen way too many projects where this stuff doesn’t get set up and then everyone wonders why the testers are holding everything up at the end.