Comment by Guid_NewGuid
3 years ago
It sounds like SOC2 compliance requirements unfortunately. Plus process overhead on who can raise tickets.
I've found compliance makes it harder to write good code. If you get a PR approval with optional suggestions you're heavily disincentivised from actually addressing those comments since if you push those changes you now need to wait for review again.
Like everything process and compliance it's designed by low-confidence managers with an inate distrust of their teams.
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.
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.
The same rigid application of process is often done in the name of Agile, when it is in fact the opposite
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.
My company is soc2 compliant and we don’t need work items to push code. Certain changes need to be approved, but they can be approved by a software engineer on one of the approving teams for the repository.
As a product manager I appreciate this take. Lots of bureaucracy is caused by a few base requirements for compliance/governance required by laws or customer need. It’s a huge time suck for PM and engineering, but I don’t know if this is avoidable. Maybe more automated verification systems?
> Lots of bureaucracy is caused by a few base requirements for compliance/governance required by laws or customer need.
Read the underlying compliance requirements carefully. In the case of e.g. SOC2, the regulation requires visibility but does not say who may open tickets or who needs to approve them. You can do a lot by making processes more open, and so long as they are still visible, you can still pass.
If specific customers tell you how to run your business, either write process that isolates their requirements to a bare corner of the business (e.g. a completely separate environment for FedRAMP) or consider firing those customers.