What Should We Do to Prevent Software from Failing?

Most building "bugs" don't result in harsh sanctions. Only catastrophic (or potentially catastrophic) ones, done with some negligence do.

Licensing isn't the solution here. Software changes too quickly, while institutionalized tests and textbooks, and certifications move incredibly slowly. Treating this industry the same as others will hopelessly slow down the already glacial pace of government software, while innovation will continue outside the system.

Software is a different realm, as other commenters point out. When faced with a problem in the software world, what's the solution? More software!

The accrediting bodies that regulators might want to form should focus on free test suites and tools for gauging security. Static code analyzers, auto penetration testers, something along these lines.

Regulate the quality of the software, not the software developers. It's easier to objectively test.

I've heard the analogy of a software developer to a mechanic, and I like it much more.

Developer = Mechanic

Computer = Car

Make = Language

Model = Platform

Year = Version

A mechanic is licensed by ASE to work on cars in the USA and there are 50 different certifications [1], depending on the type of car/truck/bus. I don't want to see software development go this route, where developers have to get multiple certifications to prove they can work on a language or platform. It would be draining and force devs into silos, even more than they already are. And as the parent comment mentions, software is an "idea" problem and not a structural/foundational one. Unless your developer is a certified genius, what good is his certification?

[1] https://en.wikipedia.org/wiki/Automotive_Service_Excellence

"Imagine joining an engineering team...You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he’s involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don’t worry, says Mary, Fred’s going to handle the walkways. What walkways? Well Fred made a good case for walkways and they’re going to add to the bridge’s appeal. Of course, they’ll have to be built without railings, because there’s a strict no railings rule enforced by Phil, who’s not an engineer. Nobody’s sure what Phil does, but it’s definitely full of synergy and has to do with upper management, whom none of the engineers want to deal with so they just let Phil do what he wants. Sara, meanwhile, has found several hemorrhaging-edge paving techniques, and worked them all into the bridge design, so you’ll have to build around each one as the bridge progresses, since each one means different underlying support and safety concerns. Tom and Harry have been working together for years, but have an ongoing feud over whether to use metric or imperial measurements, and it’s become a case of “whoever got to that part of the design first.” This has been such a headache for the people actually screwing things together, they’ve given up and just forced, hammered, or welded their way through the day with whatever parts were handy. Also, the bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts. After the introductions are made, you are invited to come up with some new ideas, but you don’t have any because you’re a propulsion engineer and don’t know anything about bridges.

Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn’t."

https://www.stilldrinking.org/programming-sucks

Licensing is not the solution.

Here are some things that can help:

1) Limit mutations, shared state, and side effects to very small sections of code. The majority of code should be pure functions and immutable code.

2) Tooling and IDE's should have "code coverage" to show where code is pure and referentially transparent and where it is not.

3) Learn from mathematics / computer science. Adopt formal methods and proof based techniques.

4) Keep code simple and understandable. Category theory has many insights on how to better compose and structure code. Code that is in harmony with certain laws will be more predictable, simpler, and more reusable. Constraints == freedom.

5) Use strong typing. And by typing I mean types that limit what values can be and even what code can do. Types that are nullable are not sufficient for safety. Types that only describe the data format and not the allowed functionality are not sufficiently safe or descriptive. Dependent typing allows for even greater safety because it can specify acceptable values ("tolerances") not just the data format of the value.

6) Adopt metrics to measure complexity and other factors that affect reliability of code. Once we have metrics we can have better discussions different ways to write the same code and why certain ways might be better under certain circumstances.

7a) Expand your vocabulary of concepts. Words affect the very thoughts you are capable of thinking about (linguistic relativity). We went from machine code to assembly to higher level languages. Each requires more concepts to know and yet it gets simpler and less error prone each time. The more words you have the easier it is to describe, write, and understand code. Category theory has many new concepts that are not in common use that improve communication and understanding. What other fields can we borrow from?

7b) Keep code short and simple to maximize understanding. More code means more surface area for software defects. 'map' is easier to understand and less error prone than 2 different arrays, counters, conditionals, increments, and mutations.

8) Typing and pattern matching provide a framework where the compiler can determine if you have handled all the cases for all possible inputs (total function). Failure to do so is a compile time error.