Regulation of the software industry [closed]

Question

Every few years someone proposes tighter regulation for the software industry.

This IEEE article has been getting some attention lately on the subject.

If software engineers who write programs for systems that expose the public to physical or financial risk knew they would be tested on their competence, the thinking goes, it would reduce the flaws and failures in code—and maybe save a few lives in the bargain.

I'm skeptical about the value and merit of this. To my mind it looks like a land grab by those that proposed it.

The quote that clinches that for me is:

The exam will test for basic knowledge, not mastery of subject matter

because the big failures (e.g. THERAC-25) seem to be complex, subtle issues that "basic knowledge" would never be sufficient to prevent.

Ignoring any local issues (such as existing protections of the title Engineer in some jurisdictions):

The aims are noble - avoid the quacks/charlatans¹ and make that distinction more obvious to those that buy their software. Can tighter regulation of the software industry ever achieve it's original goal?

¹ Exactly as regulation of the medical profession was intended to do.

Answer 1

The view that the software engineers can be pigeon-holed into the same classification as medical professionals or accountants is an ignorant view of the "problem" that they are trying to solve. Before I give my opinion on this, lets break down some of the arguments of Mr. Thornton, who is Vice Chair of the regulatory body proposing this legislation.

“Just as practicing professionals such as doctors, accountants, and nurses are licensed, so should software engineers,” Thornton says. “The public needs to be able to rely on some sort of credential when choosing a contractor to write software.”

- Mitch Thornton, Vice Chair of the IEEE Licensure and Registration

This sounds very reasonable on the surface. After all, there are other industries that might be considered "successfully regulated". By successfully regulated I mean that if you look a doctor up in the yellow pages you can be reasonably certain that he or she has had a thorough education at an accredited university and has passed a number of exams and completed a residency. Here are some "successfully regulated" industries (in terms of professional personnel).

• Lawyers
• Doctors
• Accountants
• Nuclear engineers
• Barbers (not kidding)

After all, you don't want just anyone removing that tumor from your pancreas or working on the centrifuges of that nuclear power plant just outside of town. Why shouldn't similar restrictions exist for software engineers?

Only those whose programs might “endanger the public health or safety, security, property, or the economy will need to be tested,”

This is a vague statement and open to liberal interpretation and application. I could make the argument that Apple Inc. or Facebook are integral parts of the American economy - do I need a special license from the government to write code for them now, since if I bring down the site with my incompetence I might damage the American economy? At my last job I accidentally shut down a grain elevator with a faulty cron job - possibly endangering food supply.

I realize that I'm avoiding the actual intent of this proposal. The idea behind it is to ensure that the person writing the code for the Anti-Lock Braking System on your new Jetta is competent and properly licensed to write code for an Anti-Lock Braking System. On your Jetta.

Here's the problem: software engineering in this day and age encompasses everything and you can't possibly test for every discipline. The business rules are too specific, and too varied from discipline to discipline. Our hypothetical engineer writing code for the ABS system on a Jetta might be writing something entirely different for the ABS system on an Elantra. Does he have to get re-certified?

And what if you do test for all of these derivative disciplines? Suppose for a moment that every programmer who works on an e-commerce web site gets certified as an e-commerce capable programmer. So? Does this suddenly mean that these programmers and companies will actually do the necessary validation and build to PCI compliance? Even if they do - glitches will still happen.

The exam will test for basic knowledge, not mastery of subject matter, according to Mitch Thornton, vice chair of the IEEE Licensure and Registration Committee.

Here's the kicker. A lack of basic knowledge is never the problem. My anti-lock brakes didn't stop working because Chuck was struggling with the concepts of a control structure. They failed because there was glitch where the ABS turned off due to an electrical short in the tail lights and power wasn't properly rerouted. Or something.

The insulin pump software I wrote didn't stop working because I lack basic skills; it stopped because there was a bug in how I measured the dispensure of insulin when my European teammate used the metric system and I didn't.

That's something you can account for in development, but you could never test for with a certification.

Here's what will happen if this "certification" goes into effect: the number of incidents will stay exactly the same. Why? Because it doesn't do anything to eliminate the actual problem of an ABS or insulin pump failing.

Answer 2

How fortunate that no one dies thanks to medical regulation, no one is hurt by fraud thanks to financial regulation, no one has their house foreclosed thanks to housing regulation, no one ever gets a bad haircut thanks to barber regulation, and no plane ever crashes thanks to aircraft regulation.

Obviously, the presence of regulation does not imply an absence of flaws or failures. Conversely, the presence of flaws or failures does not imply regulation would prevent those flaws or failures. Software engineers are already highly regulated as members of respective safety-critical industries, and outside of those industries there is little need.

Answer 3

History has shown, aptly I believe, that the difference between an excellent craftsman and a mediocre one cannot be tested with any form of objective measure. Basic knowledge does not make a great programmer, wisdom and experience--which cannot really be taught or measured objectively-- of how to apply that basic knowledge does.

Also, these tests usually just end up being a few buzz words and concrete procedures and fail to measure anything substantive to begin with.

If the software industry wanted to develop a guild of some sort, that would be a much better way to approach the issue. However, centralization only has the power to destroy excellence: not create it.

In addition, the problems that this measure is trying to prevent would probably not be caught by a test anyhow. Anyways, I also would love to see @ThomasOwens answer this one.

What would be the government's role, at least from American ideology, would be to hold software companies responsible for any property damage caused by their defective or insecure software. This would encourage the companies to enforce their own standards and to take personal responsibility for the matter. This is always a better solution, and it doesn't contain a centralized government overstepping its bounds.

Update

I was thinking about this some more last night over a beer or ten.

All that regulating the medical field did was to exterminate all paradigms but one. If their goal was to weed out homeopathic and naturopathic doctors, whom the o.p. kindly referred to as "quacks" then such regulation was successful. However, I disagree that such a thing is profitable for anyone except the people writing the legislation. Think about what this has done. It has driven up the cost of health care to unsustainable levels, greatly increased the liability levels for M.D.s , and has removed all of the consumer's power of choice and self-determination from the marketplace. There is no more marketplace for ideas in the medical community, and new treatments and ways of thinking about medicine are now suppressed. Furthermore, the barrier for entry into the field is incredibly high and as a result, we have a shortage of good M.D.s. In addition, the regulating agencies have the power to control the supply of doctors so that they can in turn control the price that doctors are paid.

There are indeed some gains that we have received from the medical regulation, but the costs are entirely too high.

This same thing will happen to software engineers if such regulation is passed. I can see it now, the regulating agencies will rule that object-oriented programming is the only standard of design and the functional and procedural programmers will not be allowed to practice. Then they will start telling us that we are not allowed to manage our own memory because it isn't safe. Then they will cram JAVA and C# down all of our throats and tell us we have to use it while Oracle and Microsoft get fatter and happier. Innovation will be stifled and creativity will be outlawed. Microsoft and Google will write the legislation, so the rules of the market will be bent towards their own profitability and against the social well-being.

Also, let me remind everyone that computers started out as a hobbyist and Academic endeavor. Other than the Unix wars of the 80's and early 90's we have had free operating systems, free compilers, free programs, and so on... This would come to an end quickly. The world that Richard Stallman, Linus Torvalds, and Dennis Richtie bequeathed to us will gradually fade from existence.

In summary, do I get tired of having to compete with "I'll design you a wordpress CMS site for $25 per hour" or the "any iPhone app for $500" guys? Not really, why? Because I am damn good at what I do and the customers that I want are willing to pay for excellence. When I take on a project independently or at my place of employment, I take the risk of my f*&^ ups upon my own head and reputation. That will follow me wherever I go. Also, most people know that they get what they pay for. A customer who is only willing to pay me the price that they pay their lawn guy is going to be a nightmare to deal with anyways. If the government fixed the legal structure to force service providers to compensate for their damages, then there would be very few bad programmers that still had employment in the field.

By the way, we still have bad doctors, the only difference is that there are very few forces to remove them from the market. If they had to take responsibility for their own actions, they would be out of business before they had another chance to wreak incompetent havoc upon their customers.

Answer 4

Silicon Valley News - June 31, 2015

Horror: Uncertified programmer made program abort

"I'll never be able to run again", outputs the victim. Police is investigating.

Criminal: License of Dr H. Acker Jr. revoked for incorrect use of pointer and attempts to read from system file

Advocate says there is going to be appeal to Supreme Court.

Announcements: Cobol programmers certified in 1975 should recertify no later than 2025

IEEE confirmed certification did not change since.

Ads: Certification guaranteed with Magic Knowledge Stuffers, Inc

Teach yourself programming in 21 days.

Answer 5

There are a few different ways to apply regulation to any profession - a well-defined body of knowledge, a code of ethics, accreditation of education programs, certification and licensing, and professional societies that support professional development as well as the other aspects of a profession. Software engineering has most of the characteristics of a profession.

I like to think of it as starting with the Software Engineering Body of Knowledge (SWEBOK) and the Software Engineering Code of Ethics and Professional Practice. Although common acceptance of these is still fairly limited, I think that they serve as a good base to identify the types of things that someone identifying themselves as a software engineer should have a knowledge of and how such a person should act in a professional capacity. That doesn't mean these are hard rules, but rather these documents guide professional software engineers as to what is typically relevant to the work that they might be asked to do. The SWEBOK is revised from time to time to ensure that it stays relevant.

The next characteristic is the accreditation of education programs. In the US, accreditation of software engineering programs is handled by ABET. They also accredit computer science, information technology, computer engineering, and other computing-related professions. ABET posts their requirements of accredited programs on their website - software engineering is considered an Engineering Program. The purpose of accreditation is to ensure consistency among graduates of different engineering programs, at least in terms of the subject matter taught in the classroom. It says nothing about the quality of the education.

After graduation, certification and licensing are used to assess knowledge learned in the classroom (and, in some cases, on the job) against the standard bodies of knowledge. Although the accredited schools have a defined body of material to be taught, there isn't a measure of how well this material is taught and how much students learn at the completion of the program. Certification and licensing provide methods to do that - everyone takes the same exams and demonstrates a knowledge in the various bodies of knowledge that the profession is rooted in. In software engineering, the IEEE offers certifications that are rooted in the SWEBOK - the Certified Software Development Associate for seniors and recent graduates and the Certified Software Development Professional for those with industry experience. For these to add value, it requires the acceptance of the SWEBOK as a good definition of what software engineering is.

Finally, professional societies maintain the guiding documents for the profession, facilitate conferences and publications for the exchange of knowledge and ideas, bridge gaps between academia and industry, and so on. The two leading societies are the IEEE Computer Society and the ACM, but there are other societies around the world. These wrap up everything into a nice little bundle and help deliver information to the right people.

From here, there are other questions to ask. Is the development of software an engineering discipline? Does certification or licensing add any value to software engineers? Is certification useful?

I don't think that all software development needs the rigor of an engineering discipline. That's not to say that an empirical, scientific study of the science and engineering of building software doesn't help everyone - it does. However, there's a is a big difference between developing the latest video game, developing the embedded software for a pacemaker, or building the next space craft. The emphasis is different on all of them - two of the three deserve the attention of a skilled engineer. The other can learn from engineering practices, but doesn't need to rely on them to successfully complete the project.

Certification and licensing requires an accepted body of knowledge. The SWEBOK is a good document that provides a solid foundation, but it isn't widely accepted. Unless you can base your academic programs and certification/licensing exams on something concrete that would be accepted by practitioners, then there's really no point. If the SWEBOK or alternative document becomes widely accepted (at least in those fields that require the rigor of engineering), then certification or licensing exams can be used to gauge the understanding of required knowledge.

However, there is one glaring problem with certification - it's a test on a book. Some people are good at reading, learning, memorizing, and taking a test. However, that doesn't mean they are a good engineer. People slip through the cracks all the time. A certification or license is only a single step. On the job training and mentoring by other experienced engineers is mandatory to groom a good practitioner. In addition, the ability to prevent people from practicing in critical environments can also help to mitigate the risks to society and businesses.

A good book with a fairly in-depth discussion of this is Steve McConnell's Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, and Enhanced Careers.

Answer 6

If government regulations are passed, the software industry in the USA will contract significantly, because the cost associated with meeting those regulations will be higher than startups and small businesses can afford.

The scarcity and cost associated with a Law degree or a Doctor of Medicine will become more or less visible in our industry. Not good when the alternative is that every joe could potentially build the next Facebook.

People make mistakes, and no amount of regulation will prevent disasters from occurring. Consider NASA, which has by far the most stringent requirements for software development known to man. Do they still have software bugs? (Yes, yes, and many times, yes!)

The marketplace sorts out these problems a lot better than regulations can. Companies that create software that causes problems are held responsible by the people they injured. The rest of us need not pay for their mistakes.

Answer 7

In 1999, the ACM issued a statement on licensing when it largely pulled out of the IEEE SWEBOK work. After reviewing the publicly available SWEBOK documents and the ACM statement, I support the ACM's opinion.

Glancing at the article, someone with 4-6 years of experience is required to take the exam, which tests for basic knowledge. That's beyond ridiculous, and should be laughed out the door.

Answer 8

The software components of a device are an implementation detail. For instance, in the control systems industry, all safety devices used to be hardwired, and people didn't trust software. However, we are now seeing software-based safety devices like Safety Relays and Safety PLCs. These are permissible because they still have to meet the industry regulations for safety devices (depending on the safety category). Therefore, in some cases the devices need redundant processors, and redundant code written by two different teams, etc.

It's the product that needs to meet safety guidelines if it's to be sold to and consumed by the public. Those rules don't change because the product contains software. It's the Engineer's job to make sure that the product meets all regulatory criteria, and if it contains software, then they have to review the software and be competent in that field. If they're not, they (or their company) is liable if they approved the design and it turns out to be faulty.

You don't really need to regulate all programmers just because some products need to live up to more stringent requirements. In the cases where such products involve software, you need a well-developed engineering discipline that can reliably determine that the software component meets the requirements. If anything, that's what the IEEE means: the relatively young field of Software Engineering needs to be developed to the level of reliability and trust of other engineering disciplines.

It really has nothing to do with "programming" and everything to do with "engineering".

This, of course, brings us back to the contentious issue of the difference between a developer and and engineer. These are generally two different roles that regularly overlap. The developer part means you make software. The engineering part of the role means if you stamp the design you're taking responsibility for public safety. You can be one without the other.

Answer 9

Software is already tightly regulated in the aircraft industry. See DO-178B.

I'm sure other subsets of the industry have their norms.

"Software" encompasses so much these days. I think it would be absurd to have any mandatory all-encompassing regulation.

Answer 10

Regulation of the software industry is best done through regulation of the Quality Assurance processes.

This is already done - large software companies have multitudes of testers, QA managers, automated testing suites, code review processes, testing processes, on and on. There are companies whose entire purpose is performing software quality audits on other companies. The standards organisations have guidelines for QA and for QA Audits.

Internal to a company, a software engineer is responsible for the quality of their work. Their checks and balances, however, are in the company's quality processes.

Answer 11

It's the same as most modern attempts as solving "software related problems". Those that try to legislate have little knowledge of the root course of the problem. If following the prescribed process (and the intent of course) when developing safety critical software, be that for aircrafts, nuclear plants of medical equipment a single bug will never be enough to cause a failure. An entire algorithm can be implemented incorrectly with out any one being harmed.

FDA and FTA both requires a risk analysis and based on that a mitigation strategy. The later is usually a swiss cheese strategy where one accept that any mitigation is flawed, so multiple mitigations for the same risk is applied (one mitigation might also be applied to several risks) each mitigation is like a slice of swiss cheese you can look through one, maybe two slices put together but put enough slices together and that's no longer possible. Even when the mitigations are implemented perfectly that does not result in a 100% safe piece of equipment. If the risk analysis is incorrect there will be risks no one thought of (Y2K).

You can test the engineers all you want you could even test on subject matter and require an extremely high level but it would matter much. Most safety critical errors are integration errors. They are not errors in one mans code but arise due to misalignments between software and hardware of two software systems or because an alpha particle knocked the program counter out of it's proper location.

I've been on several safety critical systems with highly experienced and capable developers, whom would pass any sensible test in their field. I've never been on a project where we did not have a safety critical error. (I've fortunately never been on one where the system ever harmed anyone)

Answer 12

One can never eliminate the charlatans and quacks completely because they exist in nearly every profession, even medical professions despite the long established practices and traditions.

On this statement being a land grab though, I am not sure what dark scary overlord of all things IT is diabolically plotting his unfettered control and regulation of software development. If you are in fact talking about the IEEE they certainly have a regulatory aspect but compliance with IEEE standards is more or less at will, and not at gunpoint. They are trying to develop universal industry standards so that we all talk the same language and increase efficiency across the board.

Further the standards that they lay out help legitimize common practices and lay the ground work for software development to eventually become a more disciplined field of engineering, not unlike mechanical engineering, or chemical engineering. While software is getting closer to that goal, it will likely never completely be a universally accepted as an engineering discipline.

The core problem is that a software developer could be doing anything from writing a pretty desktop widget, to implementing missle guidance systems. In one the severity and consequence of error is much higher than the other, and thus demands a strictly regulated engineering discipline to approach reasonably, safely, and efficiently. This is much like the severity of error in a bridge being designed incorrectly and having it collapse as a result. The designers of the bridge must be abiding my engineering standards to ensure quality.

Answer 13

I wouldn't call it tighter regulation, but instead barriers for entry. In that regard I think there is merit. For increased quality, that's very debatable.

Currently any John/Jane Doe can write a program. There is no barrier for entry. Pick up a few books on scripting and web technology and start hacking away, or worse just start Googling for how to "do" it.

When we as a collective whole decide maybe its time to increase the barriers for entry, to hold the industry to a higher standard, to evolve from hacker/craftsman to engineer, that sort of regulation I am all in on.

There are too many unqualified individuals programming today. Whether or not they work on critical systems, they are still producing code, still producing Big Balls of Mud.

In that regard, self regulation or more aptly creating barriers for entry is a good thing. Because we are saying, hey you can't just come in off the street and call yourself a Software Engineer. You actually have to demostrate a level of skill.

Demostrating skill is more than just taking a test or getting a "badge of honor". A test is just a validation. Real validation is School, internship, apprenticeship, mentoring under seniors, practicing, is all a part of it.

I can see what the IEEE is trying to achieve, but at this point it is a fruitless exercise. The industry changes rapidly, too much demand for pushing product out the door, the "hacker" mindset, etc. The regulation has to come from within if at all.

Answer 14

I haven't read the article, but if the question is about whether software industry regulation can benefit humanity, I think it depends on circumstance:

1. The industry as a whole encompasses a wide variety of domains, some of which are life critical (e.g. controlling radiation dosage in a medical device), and some of which aren't (the "Which Muppet Are You?" Facebook app). I can't see any argument for regulation for applications where the stakes are low.

2. One shouldn't start with legal regulation. Rather, one should start with a certification program for developers. Only if the certification program produces some measurable benefit should there be a question of legal regulation.

3. Even if a certification program produces measurable results, it's likely that industry would standardize on requiring this certification for strictly business reasons, and we wouldn't need legal regulation. (This is why delegations like MCSE exist - companies prefer to hire MCSEs for the domains in which MCSEs are trained.)

4. That all said, there still remain domains in which it makes business sense to cause harm (often these are negative externalities, sometimes they're the result of market power for some institutions). For example, an area may have a single local hospital; in this case, the quality of the back-end software can make a huge difference to the level of care a patient receives, but does not make that much difference in which hospital the patient chooses. The hospital then does not necessarily have much business case for investing in higher-quality developers. In this case, there may be a public-health case for regulating the developers that the hospital is allowed to hire.

IMHO.

Answer 15

I have to answer this one...

Starting with what @JonathanHenson said and the entry of @gnat, what I say is ok, people that have money can pay for certified stuff, people or countries that don't have money can't pay for licenses (so much for certified stuff), so there will still be renegades if that gets into practise. Even if traditional (and not so traditional) delivering methods are closed, people will still find ways to deliver software to interested users. Even if it means to develop another HTTP protocol or even an alternative whole network stack, only focused in making connections undetectable (see the last paragraph, for someone who might be able to do this).

Also, the idea of paying for something, is at risk, since the world is getting poorer and poorer, so more and more people will have less and less money to pay for things, there are even countries that only use FOSS software, without any certification (Brazil and India come to mind, but there are sure others), and some of those countries are getting big, really big. And they use uncertified software made by unknown programmers, whose skill is unknown.

Also, even if there is some type of certification, the certification will only certify the knowledge, not the ethics, just think that some doctors do use organs that are removed in an unauthorised way from people, so there would be also certified programmers who would have no ethics and write sloppy code either intentionally or unintentionally. While in most FOSS projects, most potentially unskilled programmers also review code from others and try to find errors, in a way that makes pair programming, something little.

At last, what do you say of hacking groups (not black hat hacker groups, but white or grey hat groups), that know much more about security and develop security software in a way that only matches the most specialised programmers from certain government departments.