who knows the code?
My blog entry on www.daanpotjer.wordpress.com
Automation is used in virtually all companies, government and other organisations. Whether using standard software or specifically written software: the code rules. But who knows the code?
Stories of old software creating problems (like the recent breakdown of services at the Orly airport near Paris because of the use of the 20-year old Windows 3.1 software), rumours of secret services using hidden backdoors or the automatic 'I approve' clicking most people do with the user agreements of consumer software, all highlight that virtually no one really knows what's in the software. No one knows the code.
Take the example of a car. Up to 20 years ago mechanics knew exactly how it worked. A piston was a piston and an exhaust an exhaust. Nowadays software rules the way a car functions. From automatic switching on of the lights to ABS systems; without software the car goes nowhere. A mechanic nowadays is more a programmer than a 'plumber'. The Volkswagen scandal illustrates that car software is extremely in-transparent and very few people, if any, really know the code.
Software developed in-house is often created by a development team. Most managers do not have the knowledge nor the means to check what has been created. They have to take the word of the development team that the code is well-written, does not contain back doors and other unwanted features and is independent from specific people for maintenance and further development.
Consumer software often provides an even better example of people not knowing what the code does. Who has a clue which data is taken from one's phone by an app? Who really reads the user agreement, and even then, who knows whether everything one normally would like to know is covered in that agreement?
Should we care? The answer is: yes, we should! Perhaps not in person, but as a society. Now our lives are impacted in a major way by code, we, as a society, should know how it really works and what it does and does not.
By creating standards, tools to vet software and heavy penalties on malware and on developing code that steals data, is dangerous for humans and otherwise is wrong and deceiving, we should change the tide of in-transparency and not having a clue. Even if we do not know the code ourselves, we should be able to trust it.
If anyone is working on, or having ideas on, tools to check the integrity and security of software, I would very much like to get into contact. Please connect through my blog: www.daanpotjer.wordpress.com.
Thank you for your help!