1<\/a><\/sup>. 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.<\/p>\n\n\n\nAnd 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.<\/p>\n\n\n\n
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?<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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?<\/p>\n\n\n\n
Or is the truth much simpler?<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Many programmers just don’t take it seriously.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
In other words, it’s time to grow up and take responsibility.<\/p>\n\n\n