Re: Interesting article ZDNet re informal software development quality

["Bruce Ediger" <eballen1 () qwest net>]

On Tue, 6 Jan 2004, George Capehart wrote:

> On Tuesday 06 January 2004 03:28 pm, Crispin Cowan wrote:
> > IMHO, this article makes the grave error of assuming that the
> > author's favorite methods are the only viable path to software
> > quality.
        ...
> to the process, it will be there.  If quality(/security) is *not*
> important to the process, it will not be there, even if the process is
> CMM Level 5.

My only beef with what both of you just said is that "quality" is sort
of a catch all.  It can (and does) mean different things:

        Fast to market
        Delivered on schedule
        Fully featured
        Fully documented
        Does not crash
        Meets 100% of requirements
        Bug free
        Looks very nice on-screen
        Runs fast
        Formally verified
        Standards compliant
        Followed some methodology

Some of these qualities are almost diametrically opposed: fast to market
often times means not fully featured, or that the application crashes
periodically.  Complying with standards may mean leaving off some set
of features.  Following a particular methodology may not give you any
of the other qualities.

The word "quality" gets used to pitch all kinds of odd things, and
tends not to have a definition.  Process people want you to agree to
use their process, so they naturally let you (and your manager, and
the CIO) imagine whatever they want for "quality".

Unless you admit publicly that tension exists between various components
of "quality", you'll go nowhere.  Different parts of your organization
will pick differ qualities to emphasize, and the whole thing falls apart
in a giant pile of gibberish and conflicting semantics.

In short, like "intuitive", don't use the word "quality".