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/charlatans1 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?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

3

I hope Thomas Owens responds to this because I know he has the perfect answer.
–
maple_shaft♦Feb 7 '12 at 17:06

3

As much as I would like to hear what people have to say on this topic, it sounds to much like a discussion question to me to be a good fit for the Stack Exchange Q&A format.
–
PersonalNexusFeb 7 '12 at 17:18

12

Frankly, I'm in favor of a constitutional amendment that creates a separation of technology and state given how clueless the Government seems to be when regulating technology (see also SOPA)
–
JohnFxFeb 7 '12 at 21:26

3

How can an industry be regulated when it changes every day?
–
Jon RaynorFeb 7 '12 at 22:02

4

Aren't a lot of these "good enough" situations that later cause bugs often the fault of management/marketing saying: "SHIP SHIP SHIP!"
–
ArenFeb 7 '12 at 23:51

16 Answers
16

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).

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.

Great answer but it only takes into account software engineering from a programmers perspective. True software engineering is in reality a team effort involving multiple skillsets and disciplines, business analysts, quality assurance, project management, etc... Incidents are just as likely a result of poor programming as they are missed requirements, misunderstood requirements, poorly managed projects and improper testing. Does the test the OP mention any of that? Of course not because it is for programmers.
–
maple_shaft♦Feb 7 '12 at 18:05

3

I would add though that I think the entire IEEE idea is rubbish to begin with. All the government has to do is its job to fix the problem. Hold everyone responsible for any damages they incur to anyone. This alone will take care of the problem
–
Jonathan HensonFeb 7 '12 at 18:06

16

Disagree with "A lack of basic knowledge is never the problem." In fact it often is the problem. How often do new programmers (or older ones) neglect input sanitization? Corner-case verification? For physical systems, I might read a sensor. It can be on or off. What about broken? How can my software tell? Then what do I do about it? Presume it is on or off? These types of "basic" things are indeed commonly at issue.
–
sdgFeb 7 '12 at 18:59

3

@JonathanHenson Then again, I consider most instances of SQL injection to be exactly that -- lacking basic knowledge... but overall, good post. +1.
–
Jeff FerlandFeb 7 '12 at 20:35

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.

I don't like the cynical tone of this answer. Are you saying there's no need for regulation, since regulation never solves any problem?
–
larsmansFeb 7 '12 at 21:12

8

I'm saying beyond a certain point, more regulation seldom solves more problems. Mandating certain software testing practices on machines capable of killing people makes sense. Tacking one more basic skills certification exam onto the end of a degree program only adds bureaucracy.
–
Karl BielefeldtFeb 7 '12 at 21:29

3

Considering the number of major corporations that have lost credit card details over the last year or so, I would say that there isn't a satisfactory self-regulation. You could argue that these systems are not life-critical - but the effect on peoples' pockets can be just as hard following these incidents.
–
HorusKolFeb 8 '12 at 1:42

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.

Though I agree with the general thrust of your statement, I find the most interesting part of it to be the very first sentence. You characterize software development as a craft, which is exactly the problem. One does not craft a suspension bridge; one engineers a suspension bridge to ensure its efficacy and safety. Software engineers still act more like crafters than engineers, no matter what title you give them.
–
Eric LippertFeb 7 '12 at 19:14

4

@Jonathan Henson: They certainly don't, in general. Lots of shops score zero on the Joel Test. (joelonsoftware.com/articles/fog0000000043.html) As to whether they shouldn't, that's a business decision not a moral decision. All those things cost money: lots and lots of money. If you're building an aircraft control system, it's profitable in the long run to take on those costs; if you're building a facebook game, maybe not.
–
Eric LippertFeb 7 '12 at 22:35

1

No, an architect stamp is as good as a PE stamp. I would certainly say that we need to incorporate many things that are currently called engineering disciplines though, just as an architect does. Architecture is still thought of as more of a craft though. Anyways, engineering is probably a craft too, so I may be just mincing words over nothing.
–
Jonathan HensonFeb 8 '12 at 3:40

1

@Andy, I suppose we should ask stack exchange to change the title of this site to softwareengineers.stackexchange.com :)
–
Jonathan HensonFeb 8 '12 at 20:04

1

@JonathanHenson Offend? No way, don't worry! :) I should have made it a bit more clearer that I posted the link just because it was weirdly coincidental to your comment.
–
Yannis Rizos♦Feb 9 '12 at 4:07

Ads: Certification guaranteed with Magic Knowledge Stuffers, Inc

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.

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.

A fantastic addition to this answer would be a list of existing software companies that would probably not have been started if these regulations were in effect. Microsoft and Facebook are a good start, since a certification would likely require a degree (almost every profession that starts with testing adds a degree requirement if they don't begin with one).
–
psrFeb 7 '12 at 18:59

1

@maple_shaft, IMO comparing doctors/lawyers to software engineering is not valid. The fields are too different to compare (see Jarrod Nettles' answer to see why you can't compare software engineering to doctors/lawyers).
–
Trevor Boyd SmithFeb 7 '12 at 19:12

1

@maple_shaft - You are implying that the certification would improve the quality of the engineering. I'm quite skeptical that would be the result. I think the time spent studying for most tests is time not spent learning better engineering.
–
psrFeb 7 '12 at 19:22

4

I believe everyone is making an unproven assumption that licensing doctors and lawyers actually improves the quality of doctors and lawyers. I am very skeptical of that assumption. All that licensing ensures is that doctors and lawyers get to charge outrageous fees and there's not a darn thing anyone can do about it. In that regard, I'm all for licensing software engineers. It won't improve the quality of software one iota, but it'll sure make a lot of us software developers wealthy. Haha when the government arrests the high school kid for practicing software without a license.
–
DunkFeb 7 '12 at 20:28

1

@maple_shaft that entirely depends on the nature of the failure - Facebook not responding isn't critical (beyond affecting investors pockets) - Facebook making all of your personal details and private messages available to every internet user is a different matter. Further - apps/games that take credit card details (like on Facebook) accidentally releasing credit card details would have serious repercussions.
–
HorusKolFeb 8 '12 at 1:50

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.

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.

+1 IMHO, what you are really hinting at is that regulation needs to be on the product, not the engineers. For example, the regulations (approvals) needed for Fire and Intrusion Alarm systems ensure the software works, not the ability of the engineers who wrote it. (Many of the regulations look much the same as when the systems were made entirely from electronic circuits.)
–
jwernernyFeb 7 '12 at 21:13

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.

This is exactly my opinion. The aviation industry has strict rules for programming quality control and testing. Companies need to audit their information assets and implement more testing and review. I think these are the dark days of software, because so many are still cutting corners by not doing what they know to be the right thing to do, and the developers themselves are not enough to change the industry.
–
TjaartFeb 8 '12 at 12:21

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)

+1 - For: "Most safety critical errors are integration errors." In fact, with all the process we go through there is almost never a coding error. 99.98% of the time it is a understanding problem between different modules and devices as to how they were supposed to work.
–
DunkFeb 9 '12 at 15:43

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.

Usually such regulations wind up being legal requirements as well. E.g., civil engineering requiring a P.E.
–
Paul NathanFeb 7 '12 at 17:19

7

I do not believe software development is ready for self-regulation, or even close to it. Frankly, the idea that "real engineers" have "real quality" is sort of a joke to me. Space shuttles have exploded, rockets have lit on fire, bridges have fallen over, buildings have collapsed... etc. It'd be nice to try to impose quality from above, but, haha.
–
Paul NathanFeb 7 '12 at 17:31

1

Comparing mechanical engineering to software engineering makes me wonder what the real-world engineering analogue would be to something like modern operating systems.
–
FrustratedWithFormsDesignerFeb 7 '12 at 17:31

1

@maple_shaft - the core problem is going to be that you can't use Linux/BSD/grep/vi/Firefox etc because they aren't written by an official SE. While someone with an MSCE cert in VB will be OK.
–
Martin BeckettFeb 7 '12 at 20:56

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.

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:

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.

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.

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.)

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.

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.

There needs to be a differentiation between software programmingversus software engineering/computer science. eg: A hello world (extreme example, granted) program is simply programming but writing cellphone modem software is engineering. Within the software industry, both these categories exist and I believe the policy should be

Anyone can write software that's not impacting a resource of public utility

Only engineers can write software that impacts resources of public utility

The definition of impact to public utility would need to be defined in dollars and/or human lives since the mapping between every software module and public utility is too vast to define in law. This can get drawn out even more into a forum discussion, addressing every corner case etc - so I'll limit my answer to the above as what I think the answer should be.

A modem driver can still be boiled down to "just" programming. And you can't define "public utility" in terns of dollars. Facebook is big money, but was made in a dorm room. (Most) computer science degrees are explicitly not engineering degrees. It depends on the school. And you'd have to overhaul academia if you wanted it to be tied to the degree people received.
–
PhilipFeb 7 '12 at 18:55

1

No, software is software, regardless of the domain. Sorry, answer is not correct.
–
Paul NathanFeb 7 '12 at 19:35

1

That's like :"Medicine is medicine, regardless of prescription seriousness". That's why only Doctors can prescribe serious medication. IMHO, the same is for serious software. SW example: The nuclear station's control systems 50 miles from my house. We're already getting the government to address each domain in specific details instead of an abstract manner in terms of public impact. eg: Theft is defined in an abstract manner instead of listing down every single way to steal something.
–
DeepSpace101Feb 7 '12 at 19:51

3

Sorry, I've seen C code for power systems and C code for the Linux kernel and C code for programming assignments. It's all code. Either it works or it doesn't. It's use-agnostic.
–
Paul NathanFeb 7 '12 at 21:22

6

Gentlemen, you may wish to take this discussion into a chat as it's coming across as argumentative, adding little value to the question. FWIW, Any smart person with an engineering title can make mistakes, and not all with qualifications are fully aware of every law, regulation, policy or standard to which they probably should be. Engineers are as fallible as others, and in both cases the outcomes can be lethal. For the majority of software developers however, their work will rarely be so critical as to require further certification, and a degree is only as good as the person who wields it.
–
S.RobinsFeb 8 '12 at 1:48