[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Benefit of policies (was Re: Triggers)

From: Paul Sander
Subject: Benefit of policies (was Re: Triggers)
Date: Wed, 2 Feb 2005 03:01:32 -0800

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]