[sirsinsalot]

I fundamentally disagree with this.

In our product, a change has the potential to cost businesses lots of money and also bring our customers into legal trouble, potentially making us liable too.

That's why we have heavy-handed change control, code vetting and so on. Yes it makes things slower, but due to the risks involved.

I've also worked on embedded projects where field updates are HARD and costly. We had heavy-handed change control then.

When I put those controls/processes in place, it wasn't due to low confidence, it was due to confidence in two things: (a) even the best SWE makes mistakes and (b) work to control change risk pays off

Sure, it isn't appropriate in many chases, but to write-off process as being designed by "low-confidence managers" because you don't see the point, is a bit myopic.

Any SWE who thinks that a codebase doesn't benefit from review before merging is driving on ego.

[Guid_NewGuid]

I see your point, I think this is the crux of the matter though:

> Sure, it isn't appropriate in many cases

I think where low-confidence management comes in is the application of the process without reference to whether the process is appropriate. It's easier to require all changes to be reviewed, every change to have a ticket and all post-approval changes to require re-approval even if the thing being edited is CSS for an internal tool than it is to build out process that accounts for the field and risk.

It feels like many places/management teams take an "off-the-shelf" compliance approach rather than constructing a process that works for the team.

[sirsinsalot]

The same rigid application of process is often done in the name of Agile, when it is in fact the opposite

[spc476]

On my team, we had a process (for nearly a decade) that lead to us being done on time, on budget, and a very low bug count that didn't involve a lot of overhead (not everything required a ticket, we did code reviews only when we thought of doing so, etc.).

New management took over (they finally realized they bought us out a few years ago), shoving "Agile" down our throats, we've missed multiple deadlines, every deployment has been a disaster, and there are still outstanding bugs that won't be fixed Any Time Soon because they're not on the release schedule.

Oh, and the new mandatory code reviews before checking in code hasn't helped since bugs still got through (and I've lost code because it wasn't checked in---it's not helping matters that we're still stuck on SVN, and half the team can't access the master SVN server).

Yeah, the overhead sure is doing great for us.

Edit: fixed typo.