The author of the article seems to pooling several different scenarios together, which isn't helpful. Regulation of IT people, performing as sysadmins, network managers etc is a wholly different discussion to whether engineers should be held liable for their code. In terms of IT staff, there may not be specific regulations but employers are entitled to ask for qualifications and references. If you perform due diligence on recruitment candidates then you should be able to at least determine if they are reasonably competent. As for authoring of software: There are already standards and requirements in place in almost every industry with regard to safety and security, and the number of regulations is growing by the week. For Automotive hardware and software, there are the ASIL (Automotive Safety Integrity Levels). System components (hardware and software) are reviewed and an ASIL level is determined. This most critical ASIL level, level D, states that failure of this component may result in serious injury or death. As such all components in that system, hardware and software will be required to be developed to certain standards, with redundancy in some components. It is the same in other industries (medical, aviation, industrial), each with its own unique standards which need a lot of effort to consume, understand and implement. For software, this can involve, code reviews, full coverage testing, software analysis tools and finally in-product validation. I wonder if the original author of the article is not aware of how much of an industry exists around getting this type of thing right. Often open-source software is excluded from such projects because of the nature of how it has been developed. It will not have been planned, developed and implemented to the requirements of whichever standard is required. I have seen threats that entire compilers would need to be re-implemented in order to be considered for a specific project. We are never going to get to a point where all software engineers are personally liable for their code for several reasons. As others have stated, liability should be with the final product and stated in the terms of the license. Regardless of how well you author your code, if someone uses it incorrectly it may become vulnerable to attack. Are you liable for how well you document your code too? If we are going to take this to its extreme, then the only people who should really be liable are the compiler developers and the runtime-library developers. In which case, gone are the days of GCC and all other open-source tools and languages, because all software engineers have to use certified compilations tools. And compilation tools will take billions to implement and maintain. Let's not even get started on what happens if I as a regulated engineer develop what I perceive to be perfect code, and then later find out that the compiler had a bug, or the runtime library had a security flaw. Am I responsible for re-engineering my code? To what timescale? In summing up m'lud, the Software industry is unlike any other industry, and comparisons with other industries is often not accurate. Software is a chaotic place where unqualified people can establish themselves without taking suitable training. Companies need to hire engineers that are qualified and competent. Companies should also make sure that they have skilled security experts who are managing their entire IT infrastructure. Hiring Software Engineers should be a rigorous process. If you want to hire Jim from admin who has taken a "Learn rust in 24 hours" course, then on you go! With all that said, I still think it is 50/50 that humanity is wiped out by a typo.

These historical artifacts of programming haven't gone away, they're still here. Runtime libraries and OO languages hide a lot of the complexity from users. There's still plenty of lists, and memory management code hanging around in the C++ runtime libraries. As a Compiler developer for DSPs we still encounter a lot of these problems. Memory is sparse, and applications need to have a minimal footprint. On some processors we need to do pointer math to calculate pointers. And while we do provide C++ support and an abridged C++ runtime library, you would be amazed at the number of users who stick to assembler and C. They are insistent that C++ is slower (which it can be if you get lost in certain parts of the language) and far more memory hungry (which is certainly is if you pull in large sections of the runtime library. But it can drastically reduce time to market. DSP's are the little brothers to your desktop CPUs that most people will be programming for. Because they're smaller with more constraining power requirements the processors are still playing catch-up to your PC. Multi-core processors are in some ways still an emerging technology. And the languages and tools used on them are steps behind too. Not to mention the conditioning of a lot of DSP developers (One of our senior chip designers (just retired) always designed his chips for assembler - "no one programs a DSP in C".)..