85

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?

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

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Flexo
  • 712
  • 2
  • 7
  • 17
  • 3
    I hope Thomas Owens responds to this because I know he has the perfect answer. – maple_shaft Feb 07 '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. – PersonalNexus Feb 07 '12 at 17:18
  • 2
    @PersonalNexus Not sure if I agree, it could all come down to the quality of the answers. The answers can be straight to the point and factual, or they can inspire discussion. – maple_shaft Feb 07 '12 at 17:22
  • @PersonalNexus - I was worried people might take that view. It definitely hits the [scope](http://i.stack.imgur.com/ociNc.png) defined in the FAQ and I think it is within the realm of [good subjective](http://blog.stackoverflow.com/2010/09/good-subjective-bad-subjective/) - it can be (and I hope will) be answered with one or more of: facts/direct observations/quantitative data – Flexo Feb 07 '12 at 17:29
  • 2
    I favorited this. I'm a bit under the weather, but I do want to answer it... – Thomas Owens Feb 07 '12 at 18:19
  • 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) – JohnFx Feb 07 '12 at 21:26
  • 3
    How can an industry be regulated when it changes every day? – Jon Raynor Feb 07 '12 at 22:02
  • @JonRaynor They'll find a way. And we'll find a way around it. – Jarrod Nettles Feb 07 '12 at 23:50
  • 4
    Aren't a lot of these "good enough" situations that later cause bugs often the fault of management/marketing saying: "SHIP SHIP SHIP!" – Aren Feb 07 '12 at 23:51
  • @RobertHarvey - I'm not 100% sure, but I thought the k vs c thing was a UK vs US issue. – Flexo Feb 08 '12 at 00:27
  • Certify managers. – detly Feb 08 '12 at 08:23
  • Therac-25 is an interesting choice of example: medical hardware was very closely scrutinised in the US before it could be used. However, the scrutiny did not include software components, so the fatal bug went undetected _because_ there was no software regulation. –  Feb 08 '12 at 10:43
  • 1
    Undetected because of lack of software regulation, or due to lack of adequate code quality? They're not the same thing. – John Saunders Feb 08 '12 at 13:50
  • 1
    Given the "expose public to financial risk" factor it could be argued that every US tax payer should be regulated and have to pass a certification prior to paying taxes but the fact is that the complexity of the tax law and conflicting facets make it impossible for one individual to fully comprehend the tax code. Software is equally complex (or more so) and regulation then becomes simply a tool of the lawyers and enforcement entities as it has with tax law while not solving the real issue and in many cases opposing effects are felt. – Mark Schultheiss Feb 08 '12 at 16:06
  • If you need to regulate anything, regulate quality control procedures. Regulating software developers is pointless. – Brendan Nov 28 '12 at 08:25

15 Answers15

104

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.

Jarrod Nettles
  • 6,125
  • 2
  • 41
  • 45
  • 33
    +1 excellent answer. I especially like: "A lack of basic knowledge is never the problem." – Jonathan Henson Feb 07 '12 at 17:58
  • 4
    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 07 '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 Henson Feb 07 '12 at 18:06
  • 1
    As someone who works in critical infrastructure, I agree that (1) incidents happen and (2) responsibility is the key point. – Paul Nathan Feb 07 '12 at 18:56
  • 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. – sdg Feb 07 '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 Ferland Feb 07 '12 at 20:35
  • @Jeff, there are certainly many instances when the problem is just plain old ignorance. I am not disputing that. However, if companies had their tails sued in court over compromised data (compensatory only, no punitive measures) then they would never have hired the idiot who didn't validate his strings and they certainly would not have given him push or commit permissions on their vc. – Jonathan Henson Feb 07 '12 at 20:44
  • @sdg by your definition, there are very few software failure that cannot be attributed to lack of basic knowledge. Software is made up of simple components -- look at any language spec. The complexity comes from the *interaction* of those simple components. – user1936 Feb 07 '12 at 21:15
  • @user1936 I was not trying to be that harsh, but was indeed quibbling with perhaps idea that testing for basics is useless. There are studies done that show experts tend to underestimate their skills, while neophytes tend to overestimate theirs; probably because the newbies don't know what they don't know. Give them enough basics to know that they don't know everything. That would help. (but not completely solve any one particular problem) – sdg Feb 07 '12 at 21:31
  • 2
    +1. Most problems I've come across as a software developer haven't been due to lack of knowledge. It's usually something closer to basic human nature. Poor attention to detail, making assumptions, ignorance, arrogance, laziness, poor communication between the customer and the various layers of management before information is passed to the developer. I really could go on. None of this relates to the basic skill set or competence of the developer, and more to do with a lack of professionalism which is something no course can teach, and no test will measure objectively. – S.Robins Feb 07 '12 at 21:35
  • 1
    Regulation on basic knowledge isn't the answer. Release gates on peer code review, on the other hand... – MrGomez Feb 07 '12 at 21:44
  • 2
    I think you underestimate the specialisations within professions like medicine and law - just as there are specialisations within software engineering, a qualified thoracic surgeon is not going to be ideal as an immunologist (and wouldn't be expected to be), or a contract lawyer is not going to be as good at criminal law. There is a basic entry-level to these professions followed by specialisation into disciplines - why can't software engineering be the same? – HorusKol Feb 08 '12 at 01:39
  • @HorusKol On the contrary - I think in that regard it is *very* similar to the medical profession. I was trying to communicate the futility of regulating the endless permutations of specialties, just like in the medical or legal profession. Maybe I didn't get that across clearly enough - I'll try and edit my answer. – Jarrod Nettles Feb 08 '12 at 01:42
  • I also find myself agreeing with your rather extreme examples - the ABS and insulin pump software should (and would) undergo extremely rigourous testing before shipping, but there may still be an edge case beyond the skill of the engineer. But, experience shows that there are many failures in systems (admittedly, non-life critical but costly to innocent victims all the same) due to shockingly bad practices (storing credit card details without any encyption is just one example). – HorusKol Feb 08 '12 at 01:56
  • @HorusKol Yes - but the edge cases you mentioned become impossible to test for. There's always something around the corner that you can't necessarily account or test for (a certification test, I mean). – Jarrod Nettles Feb 08 '12 at 02:12
  • 1
    Sorry - but I don't think of unencrypted credit card details as edge cases... that is a fundamental error- which regulation can eliminate (by providing software companies a licence which can be rescinded in the event of a fundamental error) – HorusKol Feb 08 '12 at 02:17
  • @HorusKol I wasn't referring to that particular case. I was referring to the **endless multitude** of edge cases that are unique to each particular challenge that a programmer is facing with their product. – Jarrod Nettles Feb 08 '12 at 02:18
  • And I agree that we can't regulate against edge cases - but that doesn't mean we can't regulate at all. – HorusKol Feb 08 '12 at 04:14
  • @horus but it does meant that regulations would be meaningless in a practical sense and provide a false sense of security, since most bugs aren't the simple overlooked things, but the edge cases, or interaction of simple components, etc. – user1936 Feb 08 '12 at 18:30
  • @user1936 - but you could use that argument on any regulations. Medical practice oversight doesn't prevent infections. I think the whole argument on regulations gets lost in a whole bunch of hyperbole and B$. Can regulations help create perfect software? No. Can regulations help create better software? Absolutely. The problem is getting software engineers to admit that software engineers can and do make mistakes - either through hubris, ignorance, or plain incompetence. Doesn't mean that you or I fit that mould, but there are cowboys which regulation would curtail. – HorusKol Feb 08 '12 at 22:30
  • 1
    Hey everyone, no point in continuing the discussion in comments, I think all possible arguments have already been presented. If you want to keep at it, please use chat instead. – yannis Feb 08 '12 at 22:57
  • 1
    That a grain elevator can be shut down by an errant cron job is illustrative of how entwined we have become with technology. – Robert Harvey Nov 27 '12 at 21:48
  • @JeffFerland "Then again, I consider most instances of SQL injection to be exactly that -- lacking basic knowledge... but overall, good post." SQL is a leaky abstraction is there ever was one. If anything, the widespread lack of understanding in the wide spectrum of SQL injection vulnerabilities doesn't show a lack of developer skill/effort, it demonstrates the flaws of a widely used API that wasn't designed with security in mind. – Evan Plaice Nov 27 '12 at 23:00
72

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • 10
    +1 for "Software engineers are already highly regulated as members of respective safety-critical industries, and outside of those industries there is little need" – Trevor Boyd Smith Feb 07 '12 at 19:24
  • 3
    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? – Fred Foo Feb 07 '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 Bielefeldt Feb 07 '12 at 21:29
  • 2
    @larsmans I agree with Karl, if the government is dealing with a missile or something where it believes high standards should be mandated, let them hire their own programmers and engineers according to whatever standard they choose. Private sector shouldn't be making money on public risk anyways--that is fascism. A private industry shouldn't be allowed to endanger the public to begin with. The people that know what they need best, are the people taking the risk. Let them handle their own affairs. And yes, I know that lockheed-martin and the like do this. They shouldn't be allowed to though. – Jonathan Henson Feb 07 '12 at 21:50
  • 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. – HorusKol Feb 08 '12 at 01:42
  • 1
    [Here's a list](http://www.informationshield.com/usprivacylaws.html) of just the applicable laws involving data privacy in the U.S. That doesn't include regulations, state laws, and private agreements which can result in civil penalties. That actually proves my original point that adding more regulations is no guarantee mistakes won't still occur. Certainly a licensing exam isn't going to prevent such data breaches. – Karl Bielefeldt Feb 08 '12 at 04:22
  • @JonathanHenson: but apart from the private aerospace/military industry, even companies like Facebook and many smaller ones are now capable of harming the (global!) public, because they store private information. Every now and then, an internet service leaks such info because some programmer didn't sanitize Little Bobby Tables' name. So there is a need for quality control (if not regulation) even in the non-safety-critical sector. – Fred Foo Feb 08 '12 at 09:30
  • @larsmans, that is not the public, it is a large number of people who have WILLINGLY chosen to use a service. If their data is compromised then the market will take care of things and that is the risk that they and facebook took. Facebook is not making profits on public--i.e. coerced tax payer money-- risk. And yes, there is always need for q.a., I am not denying that. I just don't want the government involved. – Jonathan Henson Feb 08 '12 at 15:07
  • @larsmans, I would also add that a corporation should not be allowed to use public property for private gain either. i.e. Exxon Mobil, Coal Mining companies, etc... Either way, my principle still applies. For most things there is no need for the government to be involved. Where they are, let them just hire whomever they choose by their own standards. Companies like facebook endanger no one except those who voluntarily use their service. If they do, the government should prevent it. Also, any damages they incur upon their customers ought to be forcibly compensated. That would fix the q.a. – Jonathan Henson Feb 08 '12 at 15:44
  • No amount of policy will correct for the underlying weaknesses of the systems people are building on. There is a whole industry (IDS) built around compensating for security vulnerabilities in SQL and they still don't have a chance against the hacker/pentester community. Regulations only work in systems where there is little or no degree of variability. Software Development is practically the *definition* of variability. – Evan Plaice Nov 27 '12 at 23:06
32

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.

Jonathan Henson
  • 5,039
  • 3
  • 26
  • 33
  • 8
    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 Lippert Feb 07 '12 at 19:14
  • @Eric I agree. Think of a wood worker. He/She has to do extensive architectural design work while simultaneously mastering the medium. Similarly a programmer has to both design the architecture of the application and master the mechanics of the machine. The work is also much more like an art form than in other forms of engineering. Anyways, "engineer" is one of those words, like "gentleman", that has lost all denotative meaning. It could mean anything and people apply it to programmers because it just sounds more professional. I think it is a very poor choice of words. – Jonathan Henson Feb 07 '12 at 19:24
  • @Eric, maybe architect would be a better choice? ... Oh wait, you can't use the word without state certification. ... I think that makes my point sufficiently. – Jonathan Henson Feb 07 '12 at 19:28
  • @JonathanHenson I disagree Engineer has lost all meaning. And you can tell the difference betwene software engineers and programmers all the time. The former, in my mind, does approach building software with engineering principles. Writing automated unit tests, careful tracking of defects, peer review of all code, etc. – Andy Feb 07 '12 at 21:14
  • @Andy, programmers don't and shouldn't do those things? – Jonathan Henson Feb 07 '12 at 21:45
  • @EricLippert: What, in your mind, would need to change so that software development is consistently approached as an engineering discipline and less as a craft? (I'd love to hear your thoughts on this, perhaps on your blog.) – Daniel Feb 07 '12 at 22:21
  • 4
    @Jonathan Henson: They certainly don't, in general. Lots of shops score zero on the Joel Test. (http://www.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 Lippert Feb 07 '12 at 22:35
  • @EricLippert, all the more reason why the government needs to stay out of it. Anyways, I also would like to read your thoughts on whether or not you prefer thinking of software development as an engineering discipline or a craft and what we should do practically to change said perception to a more desirable one. – Jonathan Henson Feb 07 '12 at 22:54
  • @jonathanhenson No, they should be. My point is that we should stop thinking of ourselves a programmers and start thinking as engineers. I always make this distinction and try to encourage more engineering discipline where ever I work. At one job I actually asked then to change my title. Sometimes this can impact salary as well if an employer is looking at salary information data from the government. – Andy Feb 07 '12 at 23:21
  • @Andy I am not sure I agree, but I am not certain why not either. I am a "software engineer" by title, but I would have to see the definition of the word before I was certain that it should be used. I don't see what is so wrong with notion of craftsmanship in our trade. Engineering sounds more scientific maybe? Anyways, I need to apply more thought to this. Thank you for challenging my ideas, it is very helpful to me. – Jonathan Henson Feb 07 '12 at 23:41
  • @JonathanHenson My personal opinion is that with craftsmanship you can have good art or bad art, but its highly subjective and I don't feel it leads to the best outcome. More scientific with tests that prove your code does what its supposed to, functions within clearly defined limits, that's ultimately what people want. Software is a means to an end. A bridge is to cross a river, for example. That's not to say you can't artfully solve a problem, but first and formost you have to solve the problem. You can have a nice looking kitchen, but if its not functional, it doesn't matter. – Andy Feb 08 '12 at 02:55
  • @Andy, but what about an architect? They build bridges and homes and so on, that solve a problem but with a certain air of creativity and art. Most architect's would not consider themselves engineers. – Jonathan Henson Feb 08 '12 at 03:00
  • @JonathanHenson Don't architects have to work closely with engineers though? I'd imagine some ideas the architect has might not be plasuible from an engineering standpoint. You raise a good point though, as developers we often are also architects of the software as well. Its not so clear cut... but I think we can stand more engineering displine in our profession. I suppose the nice thing is that we often play both engineer and architect, so we have a nice mix of both! – Andy Feb 08 '12 at 03:21
  • 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 Henson Feb 08 '12 at 03:40
  • A nit: Computers came out of the WW2 effort. *Personal* computers came from hobbyists. – Paul Nathan Feb 08 '12 at 17:56
  • 1
    @Andy, I suppose we should ask stack exchange to change the title of this site to softwareengineers.stackexchange.com :) – Jonathan Henson Feb 08 '12 at 20:04
  • @JonathanHenson [Renaming the site to match it's FAQ or changing the FAQ to match the site name?](http://meta.programmers.stackexchange.com/questions/2948/renaming-the-site-to-match-its-faq-or-changing-the-faq-to-match-the-site-name) – yannis Feb 08 '12 at 23:00
  • @Yannis, I'm not serious, read the conversation between myself and Andy. – Jonathan Henson Feb 08 '12 at 23:16
  • @JonathanHenson And why do you assume I was being serious? :P Just pointing out that the suggestion actually made it to Meta, and quite recently. – yannis Feb 08 '12 at 23:19
  • @Yannis, I am sorry. I hope I didn't offend. Stack Exchange doesn't have or tags. I am not on board with the whole engineering distinction, so I just wanted to make sure that I hadn't miscommunicated. – Jonathan Henson Feb 09 '12 at 04:03
  • 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 Feb 09 '12 at 04:07
23

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.

Community
  • 1
gnat
  • 21,442
  • 29
  • 112
  • 288
20

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.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • I'm a bit under the weather, so if I missed anything or something doesn't make sense, poke me and I'll fix it. Thanks guys. – Thomas Owens Feb 07 '12 at 19:41
  • "two of the three deserve the attention of a skilled engineer" you're right, [space craft aren't all that difficult to make](http://www.youtube.com/watch?v=MQwLmGR6bPA) – zzzzBov Feb 07 '12 at 21:06
  • +1 thanks for adding your input on the matter. I hope you get to feeling better. – Jonathan Henson Feb 07 '12 at 22:58
12

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.

George Stocker
  • 6,388
  • 2
  • 31
  • 55
  • Such regulations are absorbed easily by mature disciplines such as Law and Medicine that don't rapidly change. I personally prefer my doctor to have a license to practice medicine in my state, because if I am permanently harmed then no amount of financial restitution will satisfy. Likewise if I hire an unregulated Indian software company to write a missle guidance system and the result is 100 dead school children, then there is no question I am at fault. If they were following proper engineering discipline then at the very least I am sure that the blood is not on my hands, I did all I could. – maple_shaft Feb 07 '12 at 17:56
  • 8
    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). – psr Feb 07 '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 Smith Feb 07 '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. – psr Feb 07 '12 at 19:22
  • @maple_shaft, Your [hypothetical example of hiring](http://programmers.stackexchange.com/questions/133768/regulation-of-the-software-industry#comment250505_133775) an "unregulated Indian software company" doesn't seem valid. There are many counter examples of people who successfully outsource their software projects. – Trevor Boyd Smith Feb 07 '12 at 19:29
  • @psr It is not about the quality of engineering or software development for that matter though. It is about CYA. It is about who to blame if things go bad. If everybody acts within the constraints and standards of a confined system then blame and restitution can be more easily assessed. This is the point of all regulations. Nobody cares if Facebook fails, because profit making potential aside, Facebook doesn't compare to critical applications of software. Why regulate software that allows people to waste their time and be stupid? – maple_shaft Feb 07 '12 at 19:34
  • 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. – Dunk Feb 07 '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. – HorusKol Feb 08 '12 at 01:50
  • I don't see how such a law could be constitutional in the USA. It's not a matter of interstate commerce, foreign policy, defense, immigration, etc. It seems like something that should be left to the states. – John Saunders Feb 08 '12 at 14:00
11

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.

Daniel Pryden
  • 3,268
  • 1
  • 21
  • 21
Paul Nathan
  • 8,560
  • 1
  • 33
  • 41
10

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.

Scott Whitlock
  • 21,874
  • 5
  • 60
  • 88
  • 5
    +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.) – jwernerny Feb 07 '12 at 21:13
8

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.

Emilio M Bumachar
  • 791
  • 4
  • 6
4

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.

Bringer128
  • 809
  • 5
  • 12
  • 2
    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. – Tjaart Feb 08 '12 at 12:21
  • Great point - the software running the device is as much the company's responsibility for good and safe engineering as it is with the industrial engineering. – Jarrod Nettles Feb 09 '12 at 17:52
3

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)

gnat
  • 21,442
  • 29
  • 112
  • 288
Rune FS
  • 314
  • 2
  • 9
  • 1
    +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. – Dunk Feb 09 '12 at 15:43
  • @Dunk thanks it's actually a qoute from Levison. A fact I meant to include in the text but it would seem I forgot :) – Rune FS Feb 09 '12 at 17:18
2

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.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • 4
    Usually such regulations wind up being legal requirements as well. E.g., civil engineering requiring a P.E. – Paul Nathan Feb 07 '12 at 17:19
  • @PaulNathan Good point, which is why the natural progression to a universally accepted discipline starts at self regulation (Eg. MPAA) and eventually leads to regulation by law (State boards, FCC, etc...) – maple_shaft Feb 07 '12 at 17:25
  • 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 Nathan Feb 07 '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. – FrustratedWithFormsDesigner Feb 07 '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 Beckett Feb 07 '12 at 20:56
1

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.

Jon Raynor
  • 10,905
  • 29
  • 47
  • I give +1 for there should be some way to keep out the riff-raff from certain kinds of systems. However, I give -1 because most software today can be adequately developed by hackers and to stop them from being able to provide that service in order to keep costs down is against the public interest. Likewise, the same goes for lawyers and doctors. 90% of what they do can be handled quite cost effectively and just as competently by people with lesser qualifications. However, with today's laws they are free to gouge the public at will. – Dunk Feb 09 '12 at 15:38
  • Shouldn't skills be assessed during the hiring process. Oh wait, HR hires people based on paper credentials (which don't demonstrate applicable knowledge in software development) and HR people know absolutely nothing about the needs/requirements to develop software. Double fail... – Evan Plaice Nov 27 '12 at 23:19
0

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.

Aidan Cully
  • 3,476
  • 1
  • 19
  • 23
0

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.

Coyote21
  • 437
  • 2
  • 4