Regulating the Elephant
I recently listened (again) to some ancient .NET Rocks episodes (yes, I do like the podcast), and it got me thinking about regulation in the field of software development. In episode 774, Stephen Bohlen claims that “… somebody who calls themselves a software engineer involved in writing software for life safety systems is going to make a mistake, and that mistake is going to kill some group of people or badly injure them, and there’ll be a hue and a cry, and the industry will have lost its opportunity to regulate itself”. In episode 768, Jay Rockefeller, a United States Senator at the time, is quoted as saying “… all the apps folks, not just the big ones, but the little ones that just may have three or four people… but there are still hundreds of thousands of them, they’re pumping out apps … they’re totally unregulated… And so the question is, what do we do about that? Or what do you do about that? Or do you want us to do something about that? They have to be regulated …” Interesting conversations can also be heard in episodes 934 and 1094 with Uncle Bob Martin, and I’m sure much, much more on the topic exists in countless articles and podcasts.
How should, or perhaps how could software development be regulated, if at all? I spent quite a number of hours thinking about this (while driving at the same time, endangering everyone around me), and I came to the tentative conclusion that it may not be possible or desirable to regulate the field as a whole, in general. We may need regulation, but it should always apply to specific types of software, and it might and probably should vary widely depending on its “jurisdiction”. I also believe we might be better off regulating software “indirectly” – I explain what I mean by this below.
Look before you leap
For starters, no one in their right state of mind (with the possible exception of the Thought Police) could argue against people’s right to write software for fun. Now, once I have built an app for myself, who or what will prevent me from publishing it on my blog? I don’t have any personal experience using 1980s computers, but it’s my understanding that many programs written in BASIC back then were published in magazines, and you could manually type them into your Commodore 64. You generally had to pay for those magazines, as they were real, paper publications, and the authors, at least in some instances, were presumably paid for their work. In that case, they were making money writing software and should be subject to any hypothetical industry-wide regulation. Yet, such regulation, should it exist, would violate the First Amendment to the United States Constitution (freedom of expression), as well as the constitutional laws of any other western democracy.
While selling software products might feel like something completely different from writing magazine articles, a good lawyer could always argue that it does represent the same thing – all I’m really doing is publishing some information. Whether you read it or execute it using a machine is irrelevant, and surely the fact that you don’t have to manually retype my programs doesn’t change anything about that either. (Feel free to call me Shirley.) After all, the same copyright law applies to software and books. Even for the non-lawyers among us who might see the two as clearly different, they’re extreme examples with many shades of gray in between them – where do you draw the line?
“Somebody who calls themselves a software engineer… ”, Stephen Bohlen said. Yes, we could regulate who calls themselves what, but let me tell you something: I recently bought a plane ticket, and the website offered “travel protection”. Later during my trip I rented a car, and was offered a “damage waiver”. Both are de facto insurance policies, but because of the insurance industry’s heavy regulation, the use of the word “insurance” is off limits for a company that isn’t an insurance company. The same goes for the various extended warranties you can purchase at Best Buy. Don’t get me wrong: By no means am I arguing for a deregulation of the insurance industry. I’m merely trying to make the point that forcing people to change their job titles won’t accomplish anything. Even today, in some jurisdictions (virtually everywhere in Canada, I believe), the use of the word “engineer” is regulated, which is (one of the reasons) why we call ourselves “software developers” instead. We could regulate that too, but what would we achieve? People would simply come up with a new name.
It is also interesting to note that not only are software developers completely unregulated, but so are their products. A couple of years ago, my dad, an architect (not a software architect, but an actual one), disliked something about the CAD software he uses for work. He got so angry that he eventually suggested he would “return” it to the vendor as dysfunctional. He was genuinely surprised when I looked at the product’s license agreement, and explained to him that, like many similar license agreements, including those for commercial software, it stipulated that the application was provided “as is”, without any warranty pertaining to either quality or “fitness for a particular purpose”.
You could find this absence of any guarantee unacceptable in products you have to pay for, and although I would generally agree, I see two obstacles on the way to changing this: Firstly, unlike more traditional engineering artifacts (a bridge, for example), it may turn out difficult to precisely define the purpose of a software application: Many apps consist of a loosely related collection of features and functions, and most of the modern (and fashionable) agile approaches encourage this nebulousness. Unfortunately, you can hardly guarantee something you can’t even define. And, secondly, while we may agree that a CAD product for professional architects should come with a warranty of some sort, should the same level of rigor apply to Angry Birds? Again, I picked two relatively extreme examples, but many less obvious cases will exist somewhere between them.
Another argument against broad regulation is international competition. We may decide to regulate the industry in North America. I’m sure Europeans would gladly follow suit, if not take initiative. However, software notoriously flaunts customs checks. Not only is it impossible to prevent individuals and corporations from “importing” software, even the rules governing public contracts usually prove ineffectual. It is habitual to create or contract dummy corporations in destination countries to circumvent various “buy domestic” laws. I was once asked, in all earnestness, what percentage of the software solution we were delivering originated in the US. That I’m saying to illustrate the stupidity and futility of such efforts. If we regulate and others don’t, aren’t we giving ourselves a serious competitive disadvantage?
What about open source software? One could argue that it should be exempt from any industry-wide regulation, as it doesn’t make any money and comes with no warranty (use at your own risk), but we all know that “give something away for free and make money some other way” (services, advertising, etc.) is a frequently used business model. How about software-as-a-service applications and web sites hosted in third countries?
One final thing I’d like to add: Although the official goal of regulation in any field is consumer or customer protection, I believe that frequently a desire to curtail competition plays a role as well. In most places, it is notoriously difficult to become a practicing lawyer, for instance, even once you’ve obtained all the requisite education. While ostensibly these barriers to entry exist solely for the purpose of protecting the clients, the image of a medieval guild creeps into my mind, and I just can’t chase it out. As software developers, we are extremely fortunate in that in our field, demand still exceeds supply. This most likely will not last forever, but while it does, it enables the industry to grow and advance, something we all ultimately benefit from. Regulation may or may not increase the quality of software, but it sure as hell will make it more expensive.
Let’s see you do better
Okay, we all know you excel at criticizing, but how about you stop all this negativity for once, and try and suggest a solution, huh? (I hear people tell me this all the time, so much so that I got in the habit of saying it to myself.) Well, I can give it a shot…
I have worked on software for the electrical grid. These applications, among other things, enable utility companies to comply with NERC CIP (North American Electric Reliability Corporation – Critical Infrastructure Protection) regulations. Some of the solutions could probably be described as pretty close to what Stephen Bohlen refers to as “life safety systems”. Interestingly enough, NERC CIP places constraints on the organizations’ processes, but not the software they use. Technically, they don’t even have to use any software solution at all – they could comply simply by setting up appropriate “manual” processes. That, however, is entirely unrealistic, as the code includes rules such as “every substation device password must change at least once a year or anytime it gets exposed to any human being” – a feat more or less impossible to achieve without automation of some sort, as a medium-sized utility company may have hundreds of substations with hundreds of devices in each one, and each device may have several passwords.
Now, here’s my question: What if NERC CIP, acknowledging that the use of software represents the only realistic way to ensure compliance, created standards for the software solutions themselves, as well as their producers? This is what I mean by indirect regulation, a term I mentioned earlier. You don’t regulate the production of software, but rather place constraints on the products used in a particular setting, in this case the transmission of electricity. These requirements could pertain to the solution itself, the company delivering it, as well as the people employed at the company. The electrical grid is just an example, one that I happen to have personal experience with, and it’s not hard to come up with others: The software embedded in an elevator; in your car; applications processing sensitive medical data; financial data – you name it.
There are two points I’d like to emphasize:
- Different regulations may apply in different areas of human activity; some, possibly most, areas may remain unregulated indefinitely.
- Most of the areas that represent good candidates for regulation are probably regulated already, except the rules don’t directly apply to software.
The latter point is where I see the opportunity for change: Take currently regulated areas of human activity, and extend this regulation directly to software. The existing regulatory agencies would take on this role, although this should always be done in collaboration with people who possess a deep understanding of software development. (As anyone with any exposure to NERC CIP would attest to, you really don’t want the same people to independently write software-related regulations.) The existence of a professional software standards organization might be warranted, precisely for this advisory role.
I also find it interesting to observe that none of this is entirely unprecedented. I can think of at least one analogy: In general, no one regulates writers. Anyone (myself included!) can write anything, including, say, a scientific article. I can probably even make it look very professional. I’ll include an abstract, a literature review, present my scientific findings and opinions, a list of references… I can publish it on my blog, and because I’m feeling like Scrooge McDuck today, I’ll only allow you to see the abstract for free, and if you want the whole thing, it'll cost you $16.80 plus tax. Everything is perfectly legal, but my work will be of extremely limited value as a scientific publication: No one will take it seriously because of where it was published.
If you want to mean something in the world of science, you have to publish in reputable scientific journals. And in order to do that, you will have to meet strict criteria. You will have to work in an academic capacity for a university/college, and this institution will need to be accredited. In addition to these requirements placed on the employer, you will need probably several degrees, and unless your position is relatively senior, you will only be allowed to be listed as the second or third author, even if, in reality, you do most of the scientific work and writing. Of course your article will also have to go through a peer review process – and there’s probably much more to it than that, but I think I’ve made my point.
I see this as a form of indirect regulation: Anyone can write anything, but the use of such works, for specific purposes, is de facto regulated. I also believe that as long as we feel we need to regulate software development, we should aspire for something similar.
Nothing new under the sun
If you think about what I’ve suggested, you may notice that it isn’t that different from the rules that exist in traditional engineering disciplines. I have mentioned architecture, one of the “real”, regulated professions. I could probably create a set of blueprints for a new building, and publish it on my blog, even though I’m not a licensed architect. Anyone could download it (for free or not), but it would be illegal for them to use it to build their new dream home.
In other words, this direct/indirect division, strictly speaking, probably exists in most fields we perceive as traditional engineering, but the fact that they generally deal with the creation of physical artifacts makes it less relevant. You can really only use a set of blueprints for a house to build a house. The same holds true in most other professions: Civil engineering, electrical engineering, dentistry… What makes software development different, what makes this distinction important, is the abstract, nonphysical nature of its products.
Let me use one last example to illustrate this: Suppose I have written a cool new software system for aircraft navigation. I hope you agree that I should be allowed to sell it as a plugin for the latest version of Microsoft Flight Simulator (which is getting pretty long in the tooth, by the way), and that this should always be unregulated. The moment I decide, however, to pitch it to Boeing for use in real airplanes, it becomes a “life safety system”, which is a whole different ball game, and subjecting it to strict regulatory requirements would be completely appropriate. (Suspend your disbelief, please, for the sake of argument, and assume for a while this would be possible, both in terms of the technical feasibility of using the same software in both scenarios, and in terms of my ability to pull it off.)
If you listen to .NET Rocks episode 768, you will learn that some of this is, in a way, happening already. COPPA (Children's Online Privacy Protection Act) is a piece of United States federal legislation that regulates websites that collect and/or process personal data belonging to minors. ACT (The App Association) is an organization that aims to represent software companies in Washington, D.C. You could think of it as the standards body in an advisory role, a concept I mentioned earlier. All of this is in its infancy, and the right balance will have to be found. Current attempts at regulation probably often go too far, or not far enough. We all make mistakes, we all have to learn. I do, however, consider this to be the right direction.
Conclusion
Software professionals who choose to talk or write on the topic often express the conviction that the industry's lack of regulation is a reflection of its immaturity. Just give it some time, and software development will be more like any other established profession. While I don't necessarily disagree with them, I find this view incomplete. It fails to paint the full picture.
Software development is a very broad field. We tend to look at civil, electrical or mechanical engineering, and think of programming as just “another engineering discipline”. I believe that, in reality, its breadth could easily approach that of all engineering professions combined, and that it also shares many characteristics with other, nontechnical areas of human activity, such as writing. It is my belief that any one-size-fits-all regulation is a bad idea. Let’s regulate where appropriate, but let’s do it judiciously and selectively.
Many great things in our industry have been started by amateurs. Creativity has played a huge role. Let’s not stifle it unnecessarily in the name of becoming more professional.