Reasons Why
Address
Jonathan Vanian j_vanian@cmcrossroads.com
by Randy Wagner
Quite often 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...
Quite often 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.
Reviews (0)
Be the first to review this listing!