IME process doesn't spring fully-formed from the head of Zeus.
You get test plans when somebody goes cowboy on live code and breaks tangentially related processes. You get security reviews when somebody goes cowboy on live code, everything looks great, and then a month down the line you lose days of work when someone changes a password. You get mandates to create parameter files when someone gets burned having to run through this entire process over and over again when business rule changes back and forth.
The reality is that once this change is done the proper way and the business parameter is moved to a file, the company will never lose time over this issue again. It will be configurable just as fast and responsive as we all feel it should be, without any concerns about breaking things down the line.
Is it frustrating? Sure.
But that doesn't mean it's wrong.
Going cowboy on live code, even for something as trivial as changing a 3 to a 4, can and has created large problems.
Agreed. Process comes from a need. My point is that it sounded like the test and sec. people were not trying to speed it up. They seemed to offer little help or alternatives. Perhaps the communication process broke down. Did Ed know the importance of this change? Test and sec. certainly did not seem to.
In the enterprise, it's always an emergency. If it isn't, it gets ignored, because the pipeline for getting 'non emergencies' done is constantly pre-empted for emergencies.
That said, every good process has the ability to handle exceptions. If it was truly the emergency it sounds like, he should have been able to make the change to get it up and running ASAP and then made the change properly through the normal process.
But the question of whether an "emergency" truly is, is a complicated one.
You get test plans when somebody goes cowboy on live code and breaks tangentially related processes. You get security reviews when somebody goes cowboy on live code, everything looks great, and then a month down the line you lose days of work when someone changes a password. You get mandates to create parameter files when someone gets burned having to run through this entire process over and over again when business rule changes back and forth.
The reality is that once this change is done the proper way and the business parameter is moved to a file, the company will never lose time over this issue again. It will be configurable just as fast and responsive as we all feel it should be, without any concerns about breaking things down the line.
Is it frustrating? Sure. But that doesn't mean it's wrong.
Going cowboy on live code, even for something as trivial as changing a 3 to a 4, can and has created large problems.