Sane people, I BEG you: Stop the software defined moronocalypse

Don't drink and derive, kids

A drink driving analogy

Drunk driving is a great example here. Socially unacceptable (in cities) for decades, it remained socially acceptable in rural areas even as the first laws were being enacted against it. Through decade after decade, even into the 1990s, it remained socially acceptable to drive drunk in all sorts of corners of North America, even as an overwhelming crackdown and social campaign began.

It took generations of trying before we birthed a generation of people who nearly universally accepted that driving drunk was not acceptable. We never did fully root it out of society altogether.

When I talk about identifying driving drunk as unnacceptable, I'm not talking about people choosing not to drive drunk for their own wellbeing or the wellbeing of their family, or the desire to avoid fines. With enough effort, selfish motivations can be instilled in a significant portion of a populace fairly easily, even if it goes against what they were raised to believe.

I am talking here about a generation of people who won't let others drive drunk. Those born in the 80s and who came of age in the 90s do not – as a general rule – let others drive drunk. We have been known to take the keys away from perfect strangers if they appear to be too tanked to drive.

The push against drink driving started not long after cars themselves became mainstream. It was quiet in most corners, but it wasn't until the founding of Mothers Against Drunk Driving (MADD) in 1980 that the real crusade began.

By the 2000s, MADD had been so wildly successful that they had to shift their focus to campaigning for prohibitionism against alcohol in general, as they had become a well-trained standing army with no clear enemy left to fight. This sort of success is what needs to be replicated if we want to see security adopted by default in software development.

Friends don't let friends code in flash

If your boss ordered you to drop what you were doing at the company party, get into a company car while drunk out of your mind and rush over to a client site to solve a problem, you wouldn't do it. If, for some insane reason, you personally felt it was acceptable to climb behind the wheel drunk, your coworkers at the party would never allow it. And they'd come down on your boss like a swarm of incensed hornets for issuing you that order in the first place.

This is where we need to be with regard to security issues in application design and lack of adequate testing before shipping code. We as individuals must be willing to take the heat of standing up to our bosses and saying "no", and we need to do this not because we think the consequences will blow back on us, but because it is our responsibility to our society to do so.

We do not have the moral or ethical right to drive drunk. It is not just ourselves we put at risk but every single other person anywhere near the road. This very same sense of society obligation must be adopted by developers about the code they produce.

I understand that today's developers will not be convinced of this. We may be able to make them shape up with the right legislation as motivation, but we're not going to get to the culturally pervasive point of "you don't let anyone – even strangers – drive drunk" with today's developers.

That's fine. That's human nature. We can use legislation as a tool to coerce many – and then eventually most – of today's developers to comply with best practices.

It's the next generation we really need to focus on. We need to launch a MADD-style campaign against software development idiocy now, before robots, self-driving cars, drones and sentient weapons move beyond toys for the rich and become pervasive.

We're not going to save ourselves from the software-defined-moronocalypse. The best we can do is try to curb the damage. But if we get to our kids early enough, we can teach them to avoid the mistakes we couldn't force ourselves to stop making. I hope we do. ®