Earlier this week, Twitter was engaged in a ‘lively debate’ sparked by lawyer Steven Palley, who argued that software engineers should be licensed, insured, and have a graduate degree.
This was met by a rather predictable backlash of people asserting that this was, in fact, elitist nonsense, with counter arguments including that heaps of industry leading software engineers have no degree, and that such requirements would make the field even more inaccessible for women and people of colour.
The rejection of Palley’s self-professed “ham-handed” tweet is entirely valid – the ideas it outlines are ridiculously and unnecessarily draconian. On the other hand, however, there’s arguably a nugget of truth at the heart of them. Our lives are increasingly ruled by software, with a thousand unseen systems and processes making decisions about us and our futures.
These systems are far from infallible; a House of Commons report last year revealed that faulty Home Office IT systems could lead to a repeat of the Windrush scandal, while an automated algorithm reportedly led to Apple Card holders being allocated sexist credit limits. That’s not even taking into account situations like the Equifax incident, where poorly-managed IT infrastructure led to a wholly preventable data breach which plunged millions of people into turmoil and put them at risk of identity theft.
With so much of our lives being governed by computer systems, is it so unreasonable to demand a little more peace of mind in how they are created and maintained?
Electrical safety regulations require that businesses ensure any electronic appliances they provide to customers and employees (such as computers) are safe to use – why shouldn’t we expect the same of the software that runs on them?
We have existing frameworks to determine how critical applications are, too. GDPR includes guidelines for what constitutes sensitive personal data, so any system handling this data should be designated as critical. In addition, any system which has a direct impact on public safety and wellbeing – public transportation, healthcare and financial systems, for example – should also fall under this category.
We need to have confidence in the security and stability of these systems. And, where that’s lacking, there needs to be a level of accountability. As such, the idea of requiring that a trained and certified engineer give them the all-clear before they go into production isn’t actually all that outlandish.
So, while it’s true that software engineers don’t need a graduate degree, professional certifications like the CISSP, MCSE and CISA are a different matter altogether. These are both widely respected and widely held, and any sizeable development team should have at least a couple of people within it who hold them.
It should be part of their responsibilities to check over and approve any systems or applications designated as critical according to the guidelines outlined above, with the caveat that it’s their ass on the line if they fail, as well as the company’s.
As with other forms of safety testing and inspection, these tests would need to be repeated regularly as systems are modified and updated, but really, this is just formalising a process that should be happening anyway – regular testing and auditing of IT infrastructure is an easy and too often overlooked way to prevent breaches and outages.
Palley’s point, ham-fistedly made though it was, is that the engineering of software needs to be approached with the same care and safeguards with which you’d approach the engineering of a car or a bridge – because in many cases, the risks of harm can be equivalent or greater. In that respect, it’s sort of hard to disagree with him.
