An essay by Alex Bolboaca, 1 March 2024
Listen to the essay on YouTube, or read it below the embedded video.
This week, I followed closely the reactions to the White House recommendation for memory-safe programming languages. To my disappointment, many programmers took up to social media to poke fun, instead of admitting our collective responsibility in this situation.
I understand the reactions up to a point. Sure, having the government step in with technical recommendations is not ideal. While miles ahead of my country’s government, the White House is far from being technically proficient, so not the best at giving technical advice.
But the more important question we should ask is how did we get here? Why did the US government started to look into ways to improve programming? Could it be, and stay with me, something we’ve done?
The reason is pretty obvious once you step outside the tech bubble. Everything depends on software systems today, and we, the programmers, have largely ignored repeated problems. A line from the White House report stands out:
“For over 35 years, this same class of vulnerability has vexed the digital ecosystem.”
Back To The Building Blocks: A Path Toward Secure And Measurable Software, https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf
The frustration packed in this line is visible, and quite extraordinary given the otherwise neutral language of the document.
Ironically, a few days after the press release and the surprise expressed by many programmers online, another repeated problem has hit the software industry: the leap day, 29 February 2024. Because this day comes every 4 years, software systems around the world experience difficulties. This year was not different 1. Card payments didn’t work in a large grocery and pharmacy chain in Sweden, a cybersecurity company had issues with encryption of https connections and recommended using them without encryption, and street lights turned off in Paris. To add insult to injury, multiple smart watch models failed to show the correct date, which made me wonder how smart can they be since they can’t even figure out their core domain.
And the problems have not stopped. I can predict right now that we will have another set of leap year issues on 31 December 2024, when we will find out which programs assume that every year has 365 days.
How is it possible that an industry that produces trillions of euros and products used by virtually every human alive today is still vexed by recurrent and known problems such as leap years or memory safety vulnerabilities?
Ask programmers these questions and you can bet they find an explanation. “We don’t have enough time, managers don’t let us”. “Every program has bugs”. “It’s a QA problem”. “The industry is young”. All things I used to believe as well, since they ring true; after all we’re building bridges for 2000 years, while we only do software at scale for about 50 years. Businesses do focus on making the most money, and often pressure teams to move quickly and break things.
But do these justifications stand? Every business in the world wants to make the most money possible. Every manager pressures their teams. Everyone has deadlines, and guidelines, and rules, and often regulation. Are the programmers that special?
Or is the truth much simpler?
I propose to you an alternative explanation. We, the programmers, don’t take enough responsibility. There are things more programmers can do more often. We, the programmers, can test our own code. We, the programmers, can learn about the classes of computer bugs. We, the programmers, can check that our products work for rare events like leap years or timezone changes. We, the programmers, can learn about security attacks and how to do a little bit more to prevent them. And we should stop saying that we’re a young industry because while it took hundreds of years to figure out how to build solid bridges, we have the huge advantage of a shared knowledge base available to every single one of us.
Many programmers just don’t take it seriously.
If you want a proof, here’s an experiment. Search social media for reactions to practices that are decades old, like functional programming, clean code, design patterns, test-driven development or others, and you will find programmers who haven’t even read the books or tried them seriously just bashing them as useless and unhelpful. Make no mistake: I have no problem with anyone who actually gave them a serious try and deeply understood them coming back with a fact-based critique. My goal is to improve our practices, and intellectually honest critique is always a good thing. But the prerequisite is to take them seriously.
I can’t predict the future, so I don’t know what the aftermath of the White House report will be. But the exasperation that it transpires tells me that we have a choice: we can choose to grow up and take responsibility for our products, or responsibility will be imposed upon us sooner or later.
Our industry had it good for a long time. Hell, our companies managed to sell bugs in our code for decades and for very good money. We should not be surprised that the party is coming to an end.
In other words, it’s time to grow up and take responsibility.
- The description of the leap day bugs is based on https://codeofmatt.com/list-of-2024-leap-day-bugs/ ↩︎
