Comment by ChrisMarshallNY
3 days ago
I’m big on increasing accountability and responsibility for software engineering, but I’ve learned about SEI CMMI, and worked in an ISO 9001 shop.
In some cases, these types of structures make sense, but in most others, they are way overkill.
It’s a conundrum. One of the reasons for the crazy growth of software, is the extreme flexibility and velocity of development, so slamming the brakes on that, would have enormous financial consequences in the industry (so … good luck with that …).
But that flexibility and velocity is also a big reason for the jurassic-scale disasters that are a regular feature of our profession. It’s entirely possible for people that are completely unqualified, to develop software full of holes. If they can put enough lipstick on it, it can become quite popular, with undesirable consequences.
I don’t think that the answer is some structured standard and testing regime, but I would love to see improvement.
Just not sure what that looks like.
> but in most others, they are way overkill.
As an accountant I am able to enforce an accounts regime appropriate to my entity, with concepts like 'materiality' to help. I'm not sure about ISO9001, I'm more familiar with PCIDSS, and I found it to be very proscriptive, and 'all or nothing', compared with accounting standards. For instance in a small company, it is perfectly reasonable to state verbally to your auditor that your control over something is that you are close enough to the transactions to see misstatements by other people sat in the same room. Or even that you have too few people to exercise segregation of duties controls. In a larger company it is not ok. I don't see that same flexibility in other kinds of standards
> PCIDSS
Just got a PTSD flashback...