Comment by dofm
21 hours ago
When I said it was showing my age, this is because I went to uni nearly 35 years ago. Back then, well pre-web, at a university that turned out chartered engineers who were on many of the same modules as we were, there was a consensus building that some areas of technology would be regulated to require chartered engineers. I was on an accredited degree course from the professional body who seemed sure, any time now, that they would be the one handing out the chartered degrees (though as it turns out I never actually achieved accreditation due to a failure of communication!)
I have nevertheless always written code on the basis that it might one day encounter proper scrutiny.
Ultimately in the parallel universe where chartered software engineers became the norm, the scenarios you are talking about would be different, for structural reasons.
It's never going to happen in this universe.
I got you, but I believe a lot of the ground rules that would be in effect would make sense: a good SDLC — one that I was part of since ~20 years ago — with automated CI/CD, IaaC, reviews, constrained change requests, architectural processes, but all along very agile and able to ship quality changes in ~1-2h, was always necessary to ship good software. Building Cybersecurity and Data Privacy in from the start is the only way to really do it. Same holds for accessibility (we now do those to chase compliance instead). In a sense, I believe good SW orgs have converged to a set of rules about how you build quality SW without having those mandated.
However, I am currently in an enterprise org suffering from compliance/certification overhead while pretending that they do all of the good stuff topped with a highly infectious NIH syndrome (we build our own payment system, authentication system, wrap all the levels of cloud platforms and mobile platforms...). Trying to put more quality in gets opposition from... Quality Engineering, which is a separate department of people who've never written a line of code in their lives — because they need to be consulted and give a stamp of approval on any change, even if it's for the better :O We've got highly specialized roles of Software Architects, System Architects, System Engineers, Quality Engineering, System Validation, Software Validation, System Verification, Software Verification... It frequently becomes funny trying to make a single decision ;-) I don't have to imagine a world where something like this happens, because it exists in some enterprise orgs.
But the fact of life is that even in actual civil engineering, at every phase of building, there is a step of reviewing construction as it is built when constructions actually diverges from the project (happens quite a bit). Most of these get approved if they are not detrimental to the core function and structural integrity — this leaves the opportunity to contractors to actually do what makes more sense from their experience and still pass inspection.
This group of people would never understand that because they are mostly optimizing for appearing useful and invaluable, instead of for business or customer value.
> I got you, but I believe a lot of the ground rules that would be in effect would make sense
Yeah — perhaps unsurprisingly an industry struggling to cope with absurd complexity and change has invented and in some cases reinvented a lot of the kind of tooling and process that engineers were talking about in the 90s.