Amen!

Similar to metrics, trying to apply CM traceability to individual performance tends to work against what you're really trying to accomplish. If you're trying to figure out what went wrong, treat it as a problem to be solved, not as a witch hunt. It's okay to take up individual issues as a side bar, but wait until you know they are a pattern or a gap in training whenever possible.

Some other benefits I would add include:

It's about keeping developers working during release instead of going through the infamous code freeze.

It's about truly managing component sharing across projects and product lines.

It's about not having to manually maintain copies of source to safely experiment with new approaches.

It's about being able to fix the bug that crops up in QA without having to bring in all of the development changes that have occurred since the release.

As for how to convert an individual, that can be more difficult. If they're converted or willing to try, you have a relatively easy road. If they're resistant, you can try compelling arguments and mandates, but if they don't eventually come over, they can become a liability as they circumvent or avoid the process the whole company is using. It's similar to the person who insists on submitting their expense report as hand-written scrawl while the company is going to electronic means. Or the person who misses meetings because they refuse to use the company calendar system.

You can get a lot of mileage from understanding the real nature of the resistant developer's objections. For example, in response to an objection that it slows him down, you can counter with:

o Perforce is fast and all functions like builds take place in your local file system, just like they do without Perforce. o How much time have you spent waiting for other developers to let go of exclusive locks? o How much time have you spent trying to reconcile your changes with another developer's changes to the same file? o How much time have you lost with two or more people editing the same file and one overwriting the other's changes? o How much time have you lost making a mistake and having a hard time reversing the changes? o How many times have you spent time tracking down a bug without being able to understand how it arose? o How many times have you wanted to try something, but didn't have the assurance that you would be able to come back to the starting point if it didn't work out? o How much time have you spent sorting through manual backup copies because you lost track of when and why you made them? o How many unnecessary files have been deployed because of manual backup copies? (especially important for Web sites and applications)

These are a few and not all will apply to your product circumstances.

Steve

At 02:46 PM 2/25/2002 +0000, Chris Forman wrote: