Benefit of policies (was Re: Triggers)

[Paul Sander]

On Feb 1, 2005, at 12:13 PM, address@hidden wrote:

> [ On Sunday, January 30, 2005 at 16:45:35 (-0800), Paul Sander wrote: ]
> > Subject: Re: Triggers (was Re: CVS diff and unknown files.)
> >
> > It's not so unusual for people who have done SCM for many years on
> > large and varied projects.
>
> Well it depends -- you seem to belong to a (hopefully small and
> dwindling) group of extremely policy centered, control oriented, SCM
> managers.  Not every large shop (still) does things that way.  Lots of
> very large and diverse projects use CVS quite successfully without any
> policy enforcement at the CVS repository level.

They're successful no doubt for some value of success.  Are they able 
to ship products?  Of course.  Do the products work?  Very likely.  Can 
they do it efficiently?  With the right people, probably.  Can they 
stand some improvement (i.e. higher quality, faster throughput, fewer 
resources)?  Very likely.

> Software development and management doesn't have to be hierarchically
> and strictly controlled in the way you seem to think it should.  The
> tools don't have to get in the way of the users.  Change tracking tools
> like CVS really should only ever track changes, and the only 
> server-side
> scripting that's needed to do that is the kind that CVS more or less 
> has
> already:  hooks to make flexible site-specific reporting easier to
> implement.

I know people who have worked in shops that achieved CMM levels 4 and 
5.  Unequivocally, they really liked it.  These shops are obviously 
carefully controlled and monitored, and the metrics feed back into the 
process to remove the biggest hinderances to producing ambitious high 
quality products in short amounts of time.

The key to this is not necessarily to have control for its own sake, 
but to remove places where people screw up.  In other words, enhance 
success by removing unsuccessful elements.  Or, repeat what works, stop 
what doesn't.  That's the approach I take to making policies.  If 
something proves harmful, make it hard to repeat, or at least make it 
easy to avoid.  If someone has a best practice that has proven 
successful, use it.

Having written policies to encourage the most efficient development is 
a start.  But process automation is needed to keep things on track 
because people forget what's in the book on their shelf.

--
Paul Sander       | "Lets stick to the new mistakes and get rid of the 
old
address@hidden | ones" -- William Brown