Re: Business Week (12/6/99 issue) article on Software Quality

["John Duncan" <jddst19+@pitt.edu>]

[snip links]

Thanks for fetching those links for me.  There's also a homepage for
Cleanroom Software Engineering, but it might be down at the moment.  It
seemed like a side project of a consultant.

Further, I have this link:

http://www.amazon.com/exec/obidos/ASIN/0201385953/o/qid=945090562/sr=8-1/104
-0800228-5527666

Stavely, Allan M.  "Toward Zero-Defect Programming".  Addison Wesley, 1998

I found this book to be good, but like all process books, it does not
directly help you with your application domain.  You have to apply the
principles to your work.


Extreme Programming is a Smalltalk-spawn process framework.  My guess is
that if everyone switches to XP, more people will use Smalltalk.

http://www.amazon.com/exec/obidos/ASIN/0201616416/qid%3D945090741/104-080022
8-5527666

Beck, Kent.  "Extreme Programming Explained: Embrace Change".  Addison
Wesley, 1999.

I've been hearing a lot of good feedback from the XP folks, but, you know,
it has a sexy name.  I know that SEI has been monitoring the XP stuff
because Mark Paulk mentioned it at a SPIN meeting a few months ago.  Beware
of anything that will tell you learning a new way is easy.  The XP guys say
it is, but there is a lot of cultural change that has to take place before
it will be truly understood by your organization.

One problem with improvement is that the founding member of a new
methodology is always respected well enough to get his own way.  I am pretty
sure that Dr. Mills never had any trouble getting the precise resources he
needed to bring his vision to reality.  I also think that the C3 project,
the flagship of XP, is a very unique case.  (Not a unique application, but a
unique environment.)

To institute change, you will need to envision the company as a whole after
the change, and bring that state about.  You will need to be able to assure
people that, by following a new path, the company will be better and
happier.  You will need to show that your company is sick.  If you can't do
it yourself, shill the next highly paid consultant to pitch the plan for
you.

My advice to anyone who wants to see SPI occur in his organization is:

1.  If you go around and tell people that they are doing it wrong, you will
make enemies.  Imagine if you wrote a nifty routine, and someone told you it
was wrong because it had the wrong comment style.  This is the way process
improvement sounds when people use it in a condescending manner.  Many times
I have heard people say that they are _the_ above-average (star) programmer
in their organizations.  They say this on newsgroups, and people have to say
either, "present co. excluded" or "I'm sure you can still improve."  You may
think you've figured it out, but so has everyone else.  Look toward the
"meek", the ones who don't think they've figured it out.  They are the
easily impressionable ones.  Start discussion groups.  Never act like you
are right and "they" are all wrong.

2.  If people think bosses are the trouble, they are already overencumbered
by the system.  They need to think that the bosses show symptoms of the
systemic disease just as much as the workers do.  Do you really think that
it is upper management that is causing the problem?  Look at yourself, and
the people on your left and right.  You all have much influence on the
system, but you are probably not looking at your problems systemically.  Get
people into system thinking.

3.  If you are not a shining example of the benefits of a little process
control, people will not trust you.  Perhaps you'd get a few things done,
but if you are not actively improving, people will think it is all a joke.
Work honestly at your own self-improvement.

4.  If you show that you have stabilized the process, and then improved it
to a much more productive and stable process, the data will speak for
themselves.  If you don't have a stable base to work from, what is the
meaning of a good streak?  Every now and again a project in a Level-1 org
comes in well under budget and nearly defect-free.  Is this a testament to
the process?  No, the history will show that eventually a number of projects
will be killed for being late and costly, or full of defects.  Try to figure
out how to make everything predictable first, then work on increased
returns.

I think that the above four points will be useful.  We'll notice that
neither Cleanroom nor XP allows you to do it by yourself.  In cleanroom, you
need a bunch of people, but you can borrow them from project to project.  In
XP, you need at least two people, but to get the benefit the entire project
needs to support the paradigm.

I hope you all may have found this useful.

-John