Introduction

I have said before that the software industry should professionalize.

Where do we start? Well, if we professionalize, we will not be the first industry to do so, and we should learn from the paths that other industries have taken and what they have included required of professionals.

As far as I can tell, there are five common elements among professionalized industries:

• Standards of ethics and conduct
• A professional body with certifications and teeth
• Acceptance of liability
• Required skills
• Required knowledge

Let’s talk about each of them.

Standards of Ethics and Conduct

Not only does each professional industry have standards of ethics, they generally have the same kind of standards!

First and foremost, they are required to do the best work they can under the current limitations of the industry. This usually means that they must follow standardized best practices, which I will call a standard of care, to ensure a minimum, yet high, quality bar is met. Of course, best practices vary by industry and are built over time.

Second, there are certain behaviors and practices that are outright prohibited. These also vary by industry, but prohibited behaviors usually include things that might:

• Be illegal
• Weaken the quality of the profession
• Create conflicts of interest
• Serve the professional or the professional’s employer over the client

The first three items are obvious, so I want to focus on the last.

When a known murderer, child abuser, or other kind of criminal is brought in to a hospital for treatment, do doctors kill him? Do they even ignore him? Absolutely not! They treat him as they would any other patient. Or they should.

What about a defense lawyer? He has to represent that murderer or abuser. Does he shirk his job? I certainly hope not! Because while it may seem in society’s best interests to put that man away, it is not in society’s interest to shortcut due process, for if we did for a certain murderer, how easy would it be to scam due process for a slightly uncertain murderer, then an uncertain murderer?

Next thing you know, you need a whole organization to free innocent people from prison.

It turns out that giving individual clients the best possible service, even if it does not seem to be in society’s interests, does serve society’s best interests.

The same applies to software development.

In 2015, San Bernadino, CA was the site of a terrorist attack. One of the villains had an iPhone 5C, and the FBI wanted it unlocked for good reason. So they tried to pressure Apple to ship software that would unlock the iPhone for them. And in one of the few times I have cheered for Apple, they refused and fought the order.

Apple fought because they knew that if the FBI could force them to ship software for one particular phone, they could force them to ship that same software for all phones. Of course, I don’t know the root reason Apple fought — maybe they were concerned about their reputation — but regardless, it was the right thing to do.

Now, it might seem like it is a good thing for the government to have access to all data; it would help them find and catch criminals, right? Unfortunately, no. Because if that were true, the FBI and other agencies would be boasting about how data helped them catch criminals. But they don’t say much, so it seems the data is not helping much.

Of course, if there were no bad side effects of the collection of data, perhaps it would be okay for companies and governments to still have it. The problem is that there are side effects, and they are society-wide effects.

First, just because data isn’t used for bad now doesn’t mean it won’t be in the future. Jacques Mathheij tells a haunting story of the Holocaust in Amsterdam, where there was a registry of residents. Long before World War II, a religion field was added to this registry. And when the Nazis came, they used it to find the Jews. The data gathered by the program you wrote today could be used for murder tomorrow.

And maybe that sort of catastrophe doesn’t happen, but what does happen is social cooling, a society-wide effect that happens on an individual level.

If you feel you are being watched, you change your behavior. Big Data is supercharging this effect.

This could limit your desire to take risks or exercise free speech. Over the long term these ‘chilling effects’ could ‘cool down’ society.

This is how it works:

1. Your data is turned into thousands of different scores.

2. People are starting to realize that this ‘digital reputation’ could limit their opportunities. (And that these algorithms are often biased, and built on bad data.)

3. People are changing their behavior to get better scores.

Social Cooling is a name for the long-term negative side effects of living in a reputation economy:

1. A culture of conformity
2. A culture of risk-aversion
3. Increased social rigidity

We are becoming too transparent. This is breeding a society where self-censorship and risk-aversion are the new normal.

– https://www.socialcooling.com/

This affects you, no matter who you are. It affects your family, your loved ones, your friends. And it is the consequence of forgetting the individual using your software and making the software serve its creator and controller.

So whatever the ethics that our industry decides on, we must decide for ourselves before governments decides for us, and we must do that to ensure that our ethics is focused on serving the individual, not on serving the government. The one certain consequence of governments coming first is “a boot stamping on a human face – for ever.”

Model of Ethics

“But Gavin,” you may ask, “why are you harping on this so hard?”

Because my standard of ethics, which I have already written, is based on consequences. I don’t ask what feels good, and I don’t ask what people think is good; I reason through the likely and unlikely consequences and make a judgment.

I believe that a proper professional body should do the same, that all of its standards of ethics should be based on consequences. Of course, that body can decide what consequences it wants to avoid, but without consequences, ethics have no meaning beyond opinion.

Professional Body

So let’s talk about those consequences and that professional body because professional industries also have these things:

• a professional body
• that gives out certifications to qualified people
• with the power to revoke those certifications when standards are violated
• and the power to prevent anyone without a certification from doing certain kinds of work in the industry.

“Ugh…gatekeeping…” I hear you say.

Well, yes. While I am a firm believer that anyone can write code, I do not think anyone can write code that millions can depend on. And to make sure that our software infrastructure is as robust as our physical infrastructure, we can’t just let any rando build software any more than we would let them build power plants.

I don’t believe everyone in the industry needs to be certified anyway. Most programming could probably be done by regular, uncertified programmers; it would only be the top engineer on a project, the Engineer of Record (EoR), that would need to be certified as a Professional Software Engineer (PSWE) because the EoR will have to sign off on every bit of work. So we could still have regular programmers, and only people that want to could pursue certification.

“But Gavin,” you protest, “any gatekeeping will put some people at a disadvantage!”

Sure, but we can minimize that.

My current idea is to have an exam that anyone can study for and take. I also think that it should be paid out of the dues of current members of the professional body, not by the test takers themselves. We could even add a scholarship program to help test takers travel to the test sites.

Of course, that doesn’t help at all if you need expensive courses to study for the exam, but I think the professional body should create free Internet courses for the exam. I would even be willing to make those courses myself at no cost!

But key in all of this is no requirement for education! No college requirement, no special school, no vocational school, no training. The exam should be like bar exams of old; Abraham Lincoln was self-taught in the law, and I see no reason why professional software engineers can’t be self-taught for the exam.

But the exam is only the first step! From there, I think the professional body should give those who passed a lower certification that gives them the right to study as an apprentice software engineer. Then, and only then, can they be hired as an apprentice software engineer.

The point of an apprentice software engineer is to study and work (which must be for pay!) under a Professional Software Engineer, and the PSWE would be responsible for guiding the apprentice towards mastery of software engineering.

And when the PSWE feels their apprentice is ready, they could sit for another exam. I think this one should be both a repeat of the first exam (to ensure the apprentice is still on par) and an oral exam with one or more PSWEs, none of which should be the PSWE that the apprentice studied under.

While the purpose of the first exam should be to test all of the required knowledge for a PSWE, the purpose of the second would be to recheck that required knowledge and prove that the apprentice has the skills required of a PSWE. The oral part of this second exam should be like pilot checkrides: an intense practical exam done by a human because there is no shortcut to proving skill. And like pilot checkrides, it should have an established rubric that must be met.

But if someone were to meet all of those requirements, which includes being in good standing, I think the professional body should be obligated and required to issue a Professional Software Engineer certificate.

Now, is there some gatekeeping in that plan? Yes. Are there places where people with disadvantages could slip through the cracks? Absolutely. But done right, and with scholarships paid for by the professional body from dues by members who have already “made it,” I think that plan will minimize gatekeeping and disadvantages.

That said, in addition to the power to prevent non-certified people from acting as PSWEs, the professional body must have the power to revoke certifications for ethics or standards violations. I do think that the body should apply the same due process standards as in the US Constitution, but it should have that power because otherwise, there is no incentive to keep those standards, and professional software engineering would be a sham.

Think about it: say you’re a PSWE, and your boss tells you to add something to the software that would compromise the standards of ethics. Do you say no? Or do you go along with it?

Well, if you’re a PSWE, chances are that no matter your employment, your salary is

and you won’t want to ruin that. Plus, as a PSWE, you could probably get a job anywhere since a PSWE will be required on many kinds of projects.

Under those conditions, if your boss threatens to fire you, you can laugh in his face. Smart bosses won’t make the threat, and you can keep your ethics. Dumb bosses will, and maybe even follow through, in which case, you get a new job without much difficulty.

But for that to even be possible, the professional body must have the power to revoke certifications and to prevent non-certified people from acting as PSWEs on certain kinds of projects. With those powers, the loss from one job is nothing, but the loss of a certification could be catastrophic.

Liability

Of course, a professional body with teeth and power is a two-edged sword: as a PSWE, you could, in fact, lose your license for not just ethics, but shoddy work. In fact, I think it should go deeper because PSWEs should follow strict development practices designed to minimize bugs and enhance quality, probably through checklists, both general and specific ones.

And if a PSWE does not, he should be subject to full liability.

However, the flip side of that is that if a PSWE follows strict development practices, and the includes keeping records of following those practices, and if the failure was caused by a problem then unknown to the industry, the PSWE should not be liable.

The difference between the two is like the difference between the Tacoma Narrows Bridge collapse and the Hyatt Regency walkway collapse.

The former was caused by wind-induced oscillations at a time when they were not well-studied. The engineers faced no consequences. The latter was caused by failing to recalculate loads on a design change, something that was well-known at the time. The engineers lost their licenses.

So yes, there should be liability, but the professional body should stand by engineers who did what they were supposed to in the face of unknown problems.

That doesn’t mean that we can just require the most minimum of best practices, though; if we do, people will quickly realize that professional software engineering is a scam, and we’ll face the wrath I have mentioned before.

And when a failure happens, we can’t just not do anything; the professional body must investigate, figure out the root cause, figure out a prevention, and add the prevention to the best practices. Society will not let us make the same mistake twice without consequences, so it is in our best interests to make sure the consequences fall on the engineer who did not meet the new best practices.

Required Knowledge

When I talked about the process of becoming a PSWE, I mentioned two things the second exam must test: knowledge and skills.

Knowledge is obvious: every engineer must know certain things. This knowledge should be the basis of everything they do, and the required knowledge must reflect that. It should also be updated every year, and every PSWE should have to retest their knowledge every year to ensure they have the updates.

But there is one more aspect of knowledge that I want to talk about: domain knowledge. When I say “domain knowledge,” I don’t mean the required knowledge of all PSWEs; I mean the knowledge required to write software for particular domains.

Unlike most professions, which only have to deal with their particular brand of knowledge, software is built to model anything. This means that the knowledge required to make software includes not only general software engineering, but the knowledge required of experts in the domain that the software is modeling.

For example, I wrote a bc, which is a command-line calculator; my domain knowledge for that is math. If you are writing an accounting program, your domain knowledge is accounting. If you’re writing an operating system, your domain knowledge is hardware and its interfaces. If you’re writing software with a GUI, your domain knowledge is UX and user interface design. If you’re writing avionics software, your domain knowledge is aviation.

For every project, a PSWE must learn the domain that the software operates in. In fact, he must not become an expert beginner; he must learn it until he is competent in it, essentially mastering the fundamentals to the degree that if he starts talking with someone in that field, he can accurately identify if that person is an expert or a scammer.

So when I wrote bc, I had to master the fundamentals of math to understand the algorithms. If you are writing an accounting program, you had better understand debits, credits, accounts, account types, the accounting equation, and double-entry. If you’re writing an operating system, you must understand caches, atomics, memory models, virtual memory, and more. If you’re writing software with a GUI, you had better understand color, contrast, human-computer interaction, and human psychology! If you’re writing avionics software, it might be a good idea to get your private pilot license.

Yes, this means that a PSWE will spend a lot of time at the outset of a project learning the domain(s). But learning new domains to competence is a skill, one that can be honed.

Which brings us to…

Required Skills

Would you trust a surgeon without the skill to cut with precision? Would you trust a pilot that couldn’t follow an instrument landing system or talk with air traffic control? Would you trust a plumber who couldn’t join pipes or an electrician who couldn’t join wires?

Every profession requires a set of skills; software engineering is no different. What those skills are is something that we would need to decide, but I certainly think it should include:

• The ability to become competent in any domain in little time.
• The ability to manage a project.
• The ability to maintain software.
• The ability to mentor apprentices.
• The ability to test software.
• The ability to read and understand software written by others.
• The ability to do code reviews and pull the best out of programmers on the project.

Yes, that is a lot of other soft skills. As someone wholly incapable of such soft skills, I am aware that requiring those skills means that I could never be a PSWE, and I think that is proper. Those skills must be required.

Conclusion

We must have standards. We must have a professional body with certifications and the power to revoke them, as well as the power to prevent uncertified people from acting like they are. Professional software engineers must accept liability, but they should be protected from that liability if they follow strict development practices. They also must know certain things and have certain skills.

Without those things, I don’t think our industry could be called professional at all. I hope you feel the same.