the fly and being rather cavalier about the code base. Ultimately it’s the development staff that loses. All development should start from a known good state. When code is not worked back into the repository, we are left with a mismatch. We are almost guaranteed to put the offending issue back into production that was fixed by our coder. Hopefully we have audit functions that can catch the mismatches but we rarely have the capacity to do 100% production audits for numerous reasons. Be assiduous in tracking production changes outside normal development channels. No matter who’s at fault, some unsavory material will stick to you when bugs are reintroduced.
We'll test this one and just recompile before we release to production.
The issue at play is that testing is putting their efforts into a specific release and when code is recompiled we effectively start back at zero. The argument put forward most frequently is that if we use 99% of the original code base we remain 99% accurate. Many, many cases of new bugs are the result of the unanticipated effects of changes. Similarly, adding 1% arsenic to 99% healthy ingredients still leaves you with poisoned food. Under controlled conditions this is not necessarily a problem. When the CM takes the validated code and recompiles with a known good environment variable file, it’s completely appropriate. Adding in additional, untested code is at heart of the beast indicated in the statement above. Code may work just fine in unit testing and fail utterly in system testing.
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.
When I first heard this statement, I thought perhaps it was a function of not hearing the statement accurately. Then I thought it was a translation/accent problem. Ultimately of course, the answer was “no, you are not doing that.” The first rule of CM is don’t break production. It’s a very rare event that a set of functionality has to be released before recent production fixes can be merged back into development. Releasing old bugs is a good way of causing problems the business side wasn’t expecting. If you truly have to go down that road, the business side of the house should be fully on board and ready with their work-around.
Why don't we release it now and put the request in the CCB for approval tomorrow?
The point of the CCB is to provide a balanced, organizational view to what should be released into a given environment or pursued within a project scope. It allows various functional areas to have a say into how a given change will affect them. Ambushing them with a release before their approval can cause frustration, rework, and resentment needlessly. If you need a more flexible approach to your CCB, revamp your CCB. Devise more effective ways of communicating and approving. Don’t short-circuit your process.
The comments we receive that drive us batty, like those in this article, are often good indicators that either our process is not understood or is not serving the organization as effectively as we might hope. Sometimes it’s just a function of a project team that hasn’t quite achieved the level of maturity to which we might aspire. Regardless, that leaves it up to us to fill the gaps and provide the leg-up for the rest of the team to move to the next level.