3 ms·
What was the “reason” given to change the process? Were these changes and steps addressing something (regressions, stability, quality...)? Not saying your accou
by goliatone 9y ago
What was the “reason” given to change the process? Were these changes and steps addressing something (regressions, stability, quality...)?
Not saying your account is untrue, or that I can’t imagine management doing asinine things but it is still hard for me to imagine a) management willing to change something that’s not broken and b) developers that wouldn’t push back to said change.
- mabbo 9y agoNot all teams had moved to full-CD. Not all teams had a good set of tests, automated safe deployment windows, alarms and auto-rollback, all the things you need to deploy any software safely. This lead to high severity incidents, customer dissatisfaction. The solution, of course, is more bureaucracy! And it worked, sort of. Everyone spends all the time writing documents asking for permission to deploy software changes rather than coding, so there's less changes overall, leading to less incidents. Never mind that velocity is a fraction of what it was or might have been. In short, management wants to solve the problem in a way they understand rather than a way that works. And they love a way that has them micromanage everything and nit-pick when you didn't fill out the paperwork correctly. Now, I should caveat all this- I'm a terrible pessimist sometimes and also I haven't had any caffeine today which can only make things worse.