I'm guessing that you haven't worked at a place where it can take months to get a single line change implemented in production. This kills creators with the huge lag time between fix and implementation. I won't even go into meeting abuse.
Yeah, you've got to get those rules changed. It seems to be popular around here to call everything an "emergency fix".
(But the rules are changing. Right now, I only have to click one button to deploy to production, and it requires no manager sign-off. We hired a new CTO and that was the result :)
Obviously your employer sucks at bureaucracy. My employer has a "project and quality management system" (PQMS). Basically we have a group that sits around and thinks up more useless things that we could be documenting. Some documentation that they wanted last week is not good enough this week.
We have "phase reviews" before anything is released, no matter how minor. A "phase review" is essentially a long meeting with a dozen or more people (including one or more people from development) where the PQMS people bicker about the wording of something but no one cares that the thing does not work well. Then half a dozen people have to sign the documentation.
At the end of each sprint (we do something that we call Agile but is actually its antithesis) developers have to sign off on their peer reviews, which have been printed out. QA people have to create several documents (this seems to be QA's main function) and sign them and then everything is signed by multiple managers who know very little about what went on. We also have daily "stand-up" meetings that all development and QA people must attend. These meetings usually last 15-30 minutes but can last an hour or more. Before each sprint we have a "design review" meeting where people who know nothing about software development try to create user stories in our ticket system while everyone watches. A few days later we have a retrospective meeting and then we do sprint planning where we watch the same people who created the user stories try to enter sub-tasks for developers. Most of these meetings must be documented and of course people must sign the documents.
There is also a large repository of documents which supposedly describe every process that we use. These documents are of course inaccurate and rarely useful. A few of them are updated each week and everyone is required to read the updates.
No one, other than top executives who do not care, has any real power to dispute any new policies that PQMS creates. I should also mention that the people in the PQMS group have no understanding of software development.
BofA has all these dumb processes, and as a result, the stock market values the company at less than the total of its assets. CEOs do not make the connection between stupid policies and utter financial failure. "More policies," they say, until one day, the company is gone.
That's a big reason why I left a defense job I otherwise liked. Due to government regulations regarding contractors, every change had to be directly attributed to a request for functionality that the government generated or approved. It could take upwards of 2 months for a single one-line change, which was quite frustrating. There were spots in the code where the engineers KNEW things needed to be fixed but they weren't allowed to because they couldn't get the proper authorization.
An interesting side effect was that the group I was in made a point to use the best software engineering practices they knew (100% test coverage, all tests pass with each checkin, every checkin was code reviewed) because the engineers knew that, once code went out the door, it could be a long damned time before anyone touched it again.
I worked at a University where it would take a week to get production logs. If I couldn't find the source of the bug, I'd have to deploy a new version with a few more debugging statements, and wait another week to see the debugging in the next production logs. I eventually learned to put a hell of a lot of debugging statements in my code. I think about every other line was a debugging output statement.
