Reasons Why Software Configuration Management is Backed Against the Wall

[article]
Summary:
Quite often software configuration management 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.

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?
 
And here’s a couple bonus that I’m throwing in just because I found them funny.
    • 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:

    1. Run as fast as possible.
    2. Hold baton firmly in right hand
    3. Locate teammate ahead of you.
    4. Get in step with teammate ahead, matching pace.
    5. Move baton to specific angle in hand
    6. Hold baton at specific distance from body
    7. Maneuver into teammate’s hand
    8. Confirm grip of teammate
    9. Release grip on baton
    10. 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

Pages

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03