Small Business Programming

Learn how to be a wildly successful small business programmer

With great power comes great responsibility

I recently got into a discussion in the comments section of someone else’s blog where I argued that many software developers are overly confident in their abilities. I further argued that this overconfidence leads to the kind of behavior that would be considered professional malpractice if a lawyer, doctor, or professional engineer did something similar in their respective field.

A fellow software developer expressed an opposing view. He made the following points:

  • only a small percentage of software can cause as much damage as medical or legal malpractice and that software is highly regulated
  • if we stop people from pursuing their interests it will stifle innovation, which he was very much against

I hear variations on this view quite often and I think it is worth exploring.

Software as a force for good

Software has enabled our modern world. We can communicate with anyone virtually anywhere in the world for free or very low cost. It puts the world’s knowledge at our fingertips. It multiplies our productivity, manages our supply chains, opens up new markets, and keeps track of our money. We use software to discover new science, improve our health, and fight disease. Plus, software reduces the cost of just about everything.

And we, the software developers, are right in the middle of it and it’s glorious!

But we do have some problems

Let me paint a picture for you:

  • the industry average is 15-50 errors per KLOC for delivered software (that’s one error every 20-67 lines of code on average!)1
  • only 29% of projects completed in 2015 were considered successful (on time, on budget, with a satisfactory result). 19% of projects outright failed and the rest were somewhere in between2
  • software failures cost hundreds of billions of dollars EACH YEAR3
  • 90% of mobile health and finance apps are vulnerable to critical security risks4
  • consumer routers. Need I say more?5

Do you see what I’m getting at here? As a profession, we’re not exactly knocking it out of the park on every at bat.

Software developed for unregulated environments can’t cause that much damage. Really?

I don’t think that’s a defensible position. We (software developers) are creating plenty of harm in unregulated industries through our mistakes and negligent practices.

While our software probably isn’t directly responsible for killing people very often, I have no doubt we are indirectly responsible for countless deaths. Plus we enable property damage, theft of personal data and intellectual property, financial ruin, lost productivity, privacy violations, voyeurism, stalking, blackmail, discrimination, loss of reputation, interference in elections, espionage, and all kinds of criminal enterprises.

I can come up with links if you don’t believe me or you can just take a look at the thousands and thousands of entries in the ACM’s Risks Digest database. Here’s just a taste from recent issues:

I purposely chose examples from unregulated industries to illustrate a point. We don’t have to build drones with guns mounted on them or faulty autopilots that fly planes into mountains to hurt people and cause serious damage.

I know we kind of expect software to be terrible but keep in mind that none of these things are supposed to happen if we are doing our jobs correctly!

Evading responsibility

I expect that someone will want to split hairs in the comments about email not being secure and it not being the programmers’ fault that someone broke into the real estate agent’s email account and impersonated him because his password was “password123456”. And that might be true if you’re looking at an individual developer. But we (software developers) know how people are using email and we know better than anyone that it’s not secure but we’re doing very little about it.

We can also consider another plausible scenario. Perhaps the real estate agent created an account for some harmless website. Perhaps the website didn’t store their user’s passwords securely. Further imagine a copy of the website’s database ended up in the wrong hands and the criminals either just read the clear text passwords straight from the database or broke the unsalted MD5 hashes and recovered the password that the real estate agent used for all of his accounts.

Here, again, we know people re-use passwords and we should know better than to store them in clear text or unsalted hashes, even if our website doesn’t contain particularly sensitive information. But this could never happen, right?

The software we create is powerful, which means it can also be dangerous. So, you need to be thinking about security and the unintended consequences of any software you produce. Security isn’t just for sensitive projects.

Stifling innovation?

The claim here is that I somehow want to stop new people and ideas from entering the field and stifle innovation. I haven’t proposed any actual action and I have no power in the industry so I’d say that my power to stifle innovation is pretty minimal.

But let’s say I did propose something for the sake of argument. Maybe you can’t work on software where you’d have access to personal information if you’ve been convicted of identity theft or computer crimes. Is that an unreasonable rule where innovation is concerned?

How about this one: if you want to work with money or personal information in a system that’s connected to the Internet, you have to pass a simple test. Passing the test would show you have a basic grasp of security principles (TLS, password hashing, SQL injection, cross site scripting, maybe that it’s a bad idea to post your private encryption keys on your blog, etc.). And let’s throw in some ethics while we’re at it. Unreasonable?

I can’t think of any reason why a person who is capable of creating innovation in any area of software development would have any trouble demonstrating his or her basic competency as a programmer. Nor do I believe a reasonable testing process would stifle innovation.

Unleashing innovation

What if keeping certain people out of software development increases innovation? We know there are huge differences between the productivity of the best and the worst developers–5-28 times by some estimates6.

So what if we had some licensing mechanism to keep the worst of the worst from becoming professional software developers. Instead of having them bounce from job to job causing chaos wherever they go, maybe we could create our own version of the bar exam or something but set the bar really low. The mechanism and details aren’t important right now but just imagine if you never had to deal with another net negative producing programmer for the rest of your career. How much more could you accomplish?

Wrapping up

Pretty much every jurisdiction in the world requires people to demonstrate basic competency to drive a car. While cars are incredibly useful machines, they can also be incredibly dangerous. Ensuring the basic competency of all drivers is in the public interest. Likewise, I’d argue that ensuring the basic competency of computer programmers is also in the public interest for similar reasons.

Whether you agree with my view or not, licensing software developers is not going to happen any time soon. So, go build the next amazing thing! Please just keep in mind that any software worth building can also cause harm. So, I hope you’ll skim the Risks Digest and maybe think about the specific risks of your software and how you can minimize them.

With great power comes great responsibility.

What do you think? Agree or disagree? I’d love to hear your thoughts.

Additional resources

Here are some links you might enjoy if you want to dig a little deeper:

  1. Code Complete (Steve McConnell) page 610. If you have a 100,000 line application it will contain 1,500-5,000 errors! 
  2. Standish Group 2015 Chaos Report 
  3. The estimates are all over the map but they are all HUGE. See Software failures cost $1.1 trillion in 2016 and Worldwide cost of IT failure: $3 trillion 
  4. 90% of mobile health and finance apps are vulnerable to critical security risks 
  5. The quality of consumer routers is brutal in just about every way imaginable. And people can do bad things to you if they break into your router, really bad things 
  6. Facts and Fallacies of Software Engineering (Robert Glass) Fact 2. But I’d actually argue that the spread is infinite. I’ve met programmers who couldn’t solve a toy question in a screening interview. So their productivity is going to be zero (or negative), which makes the spread infinite. 


  1. Occupational licensing is a horrible idea. You should look into the economics of occupational licensing, public choice economics, and regulatory capture before coming to any conclusions. Nearly everywhere it is implemented licensing becomes a way for incumbents to raise the cost of entering a profession in order to prevent competition and artificially increase their own wages. It stifles innovation and competition. In nearly every industry, it is offered up as a way to keep an industry free from the worst-of-the-worst, yet time and again is captured by special interests who create taller, more expensive, and more arbitrary barriers to entry.

    • At the very least, present some evidence that any of the proposed licensing measures offer some MEASURED effect on developer performance rather than assuming the conclusion. It’s really hard to imagine that a licensing scheme would to better than individual employers who have to work with these so-called net negative programmers on a daily basis.

      • Thanks for your thoughts, Addie.

        I’m just curious if you’re against all licensing of professionals (doctors, lawyers, engineers, accountants, etc.) or is software development somehow special?

        And if software development is special and shouldn’t be regulated in any way, you’re saying that the best path forward is to continue to let employers handle it? Don’t we have quite a pile of evidence from all our failures that employers are generally not up to the task?

Leave a Reply