06 April 2009

Don't Be Quality Guy

Do not make the mistake of taking on the role in your team of the greatest advocate for improving quality. Don't be quality guy.


This was the advice given to me by an ex-colleague and he assured me it was first-hand wisdom, hard-won.

My approach has been to see things as business cases. Does quality always have a business case? This is something I've been wondering about for a long time. It certainly seems to depend on the details.

Thankfully I have never had to learn this lesson first hand. I just adopted it. I remember the look in my ex-colleague's eyes.
Posted by Chris Mountford

4 comments:

  1. Define quality.
    ReplyDelete
  2. How glib.

    You know I don't think my defining quality is really going to add clarity to this.

    Either you really don't know what software quality is in which case the whole post is useless to you OR you are trying to make a tangential point about quality being challenging to define, in which case you can choose your own reasonable definition and my colleague's advice holds.
    ReplyDelete
  3. Dude! You're advocating people shouldn't advocate improving quality because that's what someone else told you to do. If that's not being glib then my dictionary is broken. ;-)
    Unfortunately my reason for asking the question is more pedestrian than those you posit. I just wanted to know if you were talking about improving code quality, improving the quality of development processes/practices, improving product quality or some combination thereof.
    ReplyDelete
  4. There is a big difference between advocating quality and being Quality Guy.

    I'm still interested in the answer to this:

    "Does quality always have a business case?"

    I'm mostly thinking of code quality but I did say you could use your own definition.
    ReplyDelete

Subscribe to: Post Comments (Atom)