[CLUE-Talk] Software quality

[Kevin Cullis]

"Jeffery C. Cann" wrote:
> 
> On Saturday 09 December 2000 20:30, Kevin Cullis wrote:
> > If you want to keep your job, I just talked with a recruiter yesterday
> > and she stated taht the two IT shops closed up because of poor
> > practices.  If software developers AND managers don't get the hint,
> > we'll all lose our jobs down the road to India. It won't happen
> > tomorrow, but the next day turns into next year.  While I'm not trying
> > to scream like chicken little, I am trying to let you all know what's
> > coming down the pipeline. Ignoring it like Luddites won't help you in
> > the long run.
> 
> Kevin,
> 
> People have been arguing this for 25 years.  Read the 'Mythical Man Month' by
> Frederick P. Brooks, Jr.  ISBN 0-201-00650-2.

I've got it and have read it.

> 
> My point:  So called scare tactics like 'if you want to keep your job' fall
> on deaf ears.  I have not seen evidence that 'programmers from India' are any
> more qualified or concerned about quality than domestic programmers.  Despite
> the SEI certification, I would argue that if a shop is farming out
> development to save money likely does not care too much about quality (just
> my opinion).

While it might seem like scare tactics, I'm trying to point out that
higher quality wins out most of the time, not first to market sloppy
workmanship.  Read "Built to Last" and you'll get a picture of what I'm
talking about.

> 
> If you want to convince people that quality is important, you should start
> with cogent arguments that show how much less it costs to produce software if
> you build in quality checks while the system is built.

"Selling" quality requries a number of approaches to getting someone to
listen, one of which is "scare" tactics if the facts can substantiate
the fear, but it should not be the ONLY approach to getting someone to
listen and make changes to what is currently being done (I'm not for
manipulating folks by false or misleading information).  Six months ago,
I helped a guy identify an additional $600,000-900,000 over the original
$200,000 in savings if they went to Linux and the argument was refused
because "it would not be believeable" by higher ups.  Recently, that
company indicated in a newspaper article that they have to find cost
savings in order remain profitable.  What more do I need to do when my
analysis stands up to scrutiny?  Fear can also keep those in power from
making decisions.

I also know of a Director of Quality of a local Denver company that told
their #1 supplier that they would be moving to a continuously improving
quality philosophy and they wanted to partner with them to reduce
varation within their products (they were reducing the number of
suppliers they worked with but would give them longer contracts).  The
president of that supplier company thought it was FUD, until they lost
their number one customer to a rival company who was willing to invest
the time and effort in improving their quality.

FUD with facts and actions are far better than FUD alone.

> 
> The Business Week article draws parallels based on other industries, such
> as hardware manufacturing and automobile industries.  The fact is that
> building something tangible (hardware, autos) versus something intangible
> (sofware) is not comparable.

If software specs are not nailed down, then yes, it is intangible, but
specs need to be nailed down or at least the direction is clear.

> 
> I am interested in the CMM, however.  Unfortunately, this is just another in
> a long line of 'new ideas' that are never adopted.  Some previous ideas:
> 'Structured Programming', 'Object-Oriented Programming', and TQA.
> 

The principle of CMM is not a new "idea" much like gravity is not a new
idea.  The principles of quality don't change, marketing does. The
principles of quality are axioms, the sad part is that fads and
foolishness follows the rejection or refusal of those axioms.


> My experience is that the accounting of software production is not at all
> accurate.  If software development were more like a factory, then management
> would not be so reluctant to collect statistics that prove software quality
> costs less the sooner it is implemented in a project.

If software production is accounted at all, but your point is well
taken, but you don't have to be a "factory" to produce better quality,
just be able to communicate like one.

> 
> All software managers seem to think about is the product release date.  They
> have some irrational fear that if the date slips, so will sales.  If sales
> slip, then the company is in trouble.  It is extremely hard to convince these
> pin heads that the company will make a lot more money if we would test
> sooner.  When someone concerned with quality breaks into management ranks,
> their ideas never seem to get implemented.

I totally agree, but great leaders (versus management) will see that and
do the right thing.  Release dates are a goal to shoot for and having
open ended projects (date, scope, or features) can slow things down. 
The reason why most companies DON'T follow CMM style software
development is because they consider that it COSTS money to produce
higher quality software rather than increased sales are a RESULT of
higher quality.  I've had more customers yell at me because of POOR
quality that I've sold (bad products from HP) rather than higher prices.
Take a look at the Ford Taurus as being successful and it's "run" by the
"inmates."  OTOH, the Ford Explorer, which had a $8,000 profit margin
(as opposed to $1,000 for a sedan) will suffer greatly now that the
stats are out (today's paper) regarding it's highest rollover potential
and Firestone fiasco.  All that profit will go to defending itself
rather than putting into testing, now Ford's reputation is soured like
it was with the Pinto.

> 
> The US software market continues to accept (and pay for) lousy products.
> Even Ralph Nader commented on this issue  If people think the software
> they buy from Oracle or Microsoft (or Red Hat) stinks, then why on earth do
> they keep buying it?  This only feeds the cycle of non-quality assurance.  If
> consumers would say, 'I am not paying for Oracle 8i because many features I
> need are broken', then maybe Ellison and his gang of idiots would get a clue.

This is a perception which needs to be shaken up.  Internet time, while
a common theme among today's cliches, is NOT a good measure of quality. 
True cycle time reduction of a process IS. The issue of Red Hat's or
Oracle's less than good quality is one of a definition or level of
quality.  Some people will pay for C level of quality if it gets the job
done (perceived) and wouldn't think twice of A level quality.  But the
benefits of that quality need to be measured in order to demonstrate the
benefits of the additional costs and if I'm not mistaken, most companies
will not allow a comparison of their products to be published.

Let me explain a simple quality principle. How many of you trust the
accuracy of your gas gauge on your car to read 1/4 tank when the needle
is on the 1/4 mark?  Why not?  That's a quality (metrics) issue which
we've all are accustomed to, but how many of us complain to new car
dealers about this feature?  How many companies ask whether we like it? 
If a company were smart enough, they'd not only increase this accuracy,
but promote it in their literature when other cars may not have it.
However, it may not be a feature which people think would be worth a few
more bucks to pay for the accuracy. There is a difference between
negative (defects) and positive (features) quality. If the negative
outweighs the positive, sales will go down.

> 
> Like you, I want better quality in software.  I am sick of bugs that prevent
> me from getting my job completed.  Maybe Indian programmers will shock the US
> software companies into greater action.  Maybe will all be out of work soon.
> Like most things, the truth lies somewhere in the middle.  OTH - If we are
> out of jobs soon, then we can write more GNU software!

The Japanese did it to us in the auto industry during the 70's and 80's,
the Indians can do it this next decade. The key issue to developers is:
have you acquired these quality skills in your habits?  If you haven't,
find out which companies do and see what it takes to get hired by them
and what they expect and how much more they pay for these skills.

Quick question: if the price is cheaper in India and the quality is the
same between American and Indian software quality, who do you think will
win contracts from businesses (all else being equal)?  If it is cheaper
to pay for Level 5 CMM level quality in India than it is for Level 2
quality in America, where do you think that business will go?  Would you
want to move to India to get a job?  I didn't think so.  The only
recourse is for software developers to learn process improvement at each
person's level and how it fits into the bigger picture.

I hear that the best compiler is the free stuff.

Jeff, as always, I like your comments.  It'll take a while to reach the
PHB's, but maybe one day they'll wake up. It took Deming almost 30 years
of saying the same thing before they started listening to him in the
1980's and following is direction.  I just hope the software industry
won't take that long.

Kevin