Quite often software configuration management (SCM) is backed against the wall because following the process is going to cause someone a delay, or worse yet, inconvenience. Using a bit of bit humor, we’ll look at some common complaints and the underlying reasons why we put the rules in effect in the first place.
Here they are in no particular order.
- Why do I have to write a separate issue record for each item? Can't I just lump them all in one?
This can't be tested, just put it in production.
It was only one line of code, what's the big deal?
No, no, we use a serious CM tool -- VSS!
I'll just modify the file in production. We can copy it to the repository later.
We'll test this one and just recompile before we release to production.
They fixed that in production but we haven't retrofitted it to development yet. We'll just promote ours to production and re-fix it later.
Why don't we release it now and put the request in the CCB for approval tomorrow?
- What you are seeing can't be happening. I'm certain.
- Don't use the words "bug" or "defect." That would automatically imply there was something wrong with the code. It's an "issue.” We don’t want to upset the developers.
Each of those items would suggest that following process in just burdensome and gets in the way of “real work.” Inherently, project teams seem to achieve an almost mythic capacity for optimism when debating on how much process is necessary. Conceived and executed properly, process will save time and money and, possibly, a career or two. But this cost savings comes at an organizational level, rather than individually.
Consider this process:
- Run as fast as possible.
- Hold baton firmly in right hand
- Locate teammate ahead of you.
- Get in step with teammate ahead, matching pace.
- Move baton to specific angle in hand
- Hold baton at specific distance from body
- Maneuver into teammate’s hand
- Confirm grip of teammate
- Release grip on baton
- Reduce speed and move off track
Ten steps for just one part of a relay race. Can we do the relay without the process? Sure we can. Can we hope to be the race winners without it? Doubtful. It may be more comfortable for a runner to hold the baton in the left hand. Perhaps the angle of the baton at transfer is awkward. But this is the type of process we want to achieve. Each individual in this example is motivated to deliver in a way that specifically contributes to the project’s bottom line (winning the race) and reduces their own potential for failure. The project team quotes early in the article reflect a team that isn’t working together or isn’t aware of the potential conflict they are causing themselves.
Let’s look at the first example.
Why do I have to write a separate issue record for each item? Can't I just lump them all in one?
Lumping issues together into one record causes several issues. First, the record cannot be passed until every issue listed is satisfied. This typically causes the most difficulty at the end of a project phase when the team is debating on which issues to defer to the next phase. It causes frustration from a traceability standpoint. I now have code labeled or packaged for release