From: Bob Stout 

On Sun, 25 Apr 2004, Bruce D. Wedding wrote:

> 1.  Planning - Prioritize the next release by combining business
> priorities with technical estimates.  Basically, perform the changes in
> priority order.

This restates the obvious.

> 2.  Small Releases - Release new versions constantly, build everyday.

Also a good idea. The reason it's good is that it enforces frequent testing.

> 3.  Testing - Continuous unit testing.  Tests are written as code is
> written.  Customers write and run feature tests.  An integration test
> must be run at each build.

Again, this *should* be restating the obvious, but frequently it's not done.

> 4.  Refactoring - Continuous refactoring.  Simplify, remove duplication,
> add flexibility.

Improving algorithms is the most reliable way to enhance software quality.
However, if there's more than one programmer working on it, coordination
and communication become major issues.

> 5.  Pair Programming - production code is written with 2 programmers at
> each machine.

Bull sh*t!!! I won't/can't work productively either with someone looking
over my shoulder or holding someone else's hand. I've actually quit jobs
rather than be stuck with this sort of arrangement.

> 6.  Collective ownership - anyone can change any part of the code.

Collective ownership = collective responsibility = no responsibility or
accountability. This could only work if everyone had the same level of
knowledge and experience. Otherwise, you will have well-meaning but
clueless tyros "improving" critical code.

OTOH, this *could* presume that everyone *does* have the same experience,
namely that the entire group is on the bottom rung of the ladder. More on
this, though, at the end of my comments.

> 7.  Continuous Integrations- integrate and build many times a day.

I'm sure this creates the illusion of productivity among those who can't
tell the difference between movement and progress.

> 8.  40 hour week - No overtime or very limited overtime

I have always scheduled 40 hour weeks. The problem is those who practice
poor scheduling or deliberately abuse their salaried employees. Done right,
employees should rarely feel obliged to work overtime because it shouldn't
be necessary in a well-planned project.

> 9.  On site customer - A real user, whatever that is, on site all the time

That may or may not be practical/feasible. I have that all the time right
now, but then I program embedded systems that are used as part of the
service the company sells.

Despite the traditional antipathy between the departments, this is what a
marketing department is *supposed* to do. Whether they do so in practice is
another issue.

> 10. coding standards - All write according to rules emphasizing
> communication through code.

Again, restating the obvious.

One thing none of your description addresses is how well the scheme
supports CMM. Forget ISO-9000, CMM is the only valid metric for companies
trying to insure software quality. Any scheme which doesn't clearly address
responsibility and accountability will have problems in a CMM enhancement
environment. From my perspective, your description has lots of room for
denied responsibility and finger pointing when things go wrong (and, sooner
or later, things *will* go wrong!)

> OK, in a nutshell, I like it.  I can see how it would have helped many
> of the large projects I've worked on.

It might be OK in a typical desktop environment where everyone is using
CASE or RAD tools. But when you get to a situation where real programmers
are writing real programs rather than letting a machine patch together
boiler plate, you need a responsible architect and a coherent design
strategy.

> The one I have an issue with is pair programming.  I did it once when I
> had no choice for 4 months and I hated it.  Of course, it may have been
> the person I was working with but I'm reluctant to try again.  In pairs,
> people have to be flexible and willing to listen.  My partner was not.
> It was HER way or else she'd throw a fit or just ignore you and do it
> her way anyway.

I've been there. The whole "pair programming" thing sounds like a
corporate strategy to hire lots entry level programmers and force them to
interact, hoping they'll make up in epiphanies what they lack in experience
and depth of knowledge.

> So, what do you all think?

Except for the restatements of the obvious ("breathing is good"),
I'm generally underwhelmed. From what I've seen, most management fads have
their basis in companies trying to minimize payroll costs without
sacrificing quality or functionality. That's not necessarily a bad goal,
but the fact that each year brings new fads tells us that each one has
flaws. The obvious solution - to recruit the best staff possible, give them
room to be creative, and retain them by treating them fairly - flies in the
face of conventional business wisdom today.

-------------------------------------------------------------
Consulting: http://www.MicroFirm.biz/ Web graphics development:
http://Image-Magicians.com/ Software archives:
http://snippets.snippets.org/
  c.snippets.org/   cpp.snippets.org/      java.snippets.org/
  d.snippets.org/   python.snippets.org/   perl.snippets.org/
  dos.snippets.org/ embedded.snippets.org/ apps.snippets.org/
Audio and loudspeaker design:
  http://LDSG.snippets.org/   http://www.diyspeakers.net/

--- BBBS/LiI v4.01 Flag-5