Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Should software engineers be certified?

Malcolm Isaacs Senior Researcher, Micro Focus

Wikipedia states that an engineer, in addition to having specialized education and being licensed, has obligations to the public, clients, employers, and the profession—as well as a code of ethics that engineers pledge to uphold.

While the software engineering community does not have a formal regulatory body, there are organizations such as the British Computer Society, the Association for Computing Machinery, and the IEEE Computer Society. But these are not governmental organizations, and only a small number of people I’ve met throughout my career are actually members.

We interact with digital services multiple times every day and freely divulge information to people and organizations about which we know very little, and we have no idea what they will do with that data. Even legitimate websites and services can fall short of diligently protecting the data; we’ve all heard of WikiLeaks and the Panama Papers.

Can we trust the people who design, operate, and maintain access to these systems? Do we need formal regulation in the software industry?

I sat down with Robert Youngjohns, executive vice president and general manager of Hewlett Packard Enterprise Software, who says we should trust the people working on our systems but, at the same time, must employ cutting-edge monitoring and analytics technology to protect the organization and the data. Here are the main points from our discussion.

Formal regulation of software engineers is impractical

The fact that software engineers are distributed across many different countries makes certification more difficult.

“Living in California, if you have electrical work done on your home," said Youngjohns, “you generally need to hire a California-certified electrician, because there’s actual physical work that needs to be done. Of course, you could get a noncertified one, but on the whole, the risks of doing so outweigh the costs of getting a local certified contractor. In the software industry, there’s no locality any more. An electrician or a plumber has to physically show up at your house. A software engineer, on the other hand, could be anywhere—Bangalore, Shanghai, or Ulan Bator. That makes it's far harder to create a common regulatory framework, because you’d almost by definition have to be global.”

“The track record of creating global certification or regulation is not good, to say the least. During my career to date, I have seen various attempts to establish multinational standards, whether it’s a standard for document transfer, mail, or something similar. Usually the standard lags behind the market by a decade, and by the time it gets done, it can simply be irrelevant, even more so in the fast-moving world of technology.”

Trust people to do their jobs

Since formal regulation of software professionals is not realistic, we need to find people on whom we can rely and give them the latitude they need to do their job.

"Early in my career, when I joined the British Civil Service, it had a very different approach to security from the US equivalent. The British approach was to interview hundreds of people to find out whether you’re a ‘decent chap,’ of good moral fiber. If you are, you were let in. Once you were accepted or cleared, there was limited control imposed on how you did your job. The US at the time, however, would administer polygraph tests and impose tight security, including searching employees each time they came in and went out. They would also monitor employee telephone calls. The British approach was to assume that as long as people are selected as trustworthy, they can be trusted going forward. The US approach was to assume that everyone required ongoing, rigorous monitoring."

Living in California, if you have electrical work done on your home you generally need to hire a California-certified electrician.

“However, human beings have a remarkable capability to bypass controls. It’s often done not out of mal-intent; it’s done out of convenience. A classic example is access to confidential data. In a previous job, we had to use digital rights management (DRM) in an attempt to control document distribution via email. We found that people got so frustrated by it that they would end up taking the document and putting it onto a DropBox-like service and bypass the control system completely. That made the document far more vulnerable than it would have been had the control not existed in the first place.“

But use technology to verify

People must be allowed to work unimpeded, but still, we must be vigilant.

“Rather than attacking the problem at source and requiring every single programmer to hold some certification, there is an argument to say that we should just accept that if they can program in Perl or Java, or Python or whatever, they can be a good coder. But at the same time, use machine learning and analytics to ensure that they’re not adding vulnerabilities knowingly or unknowingly into the system. Rather than build up controls and processes, we at HPE Software are focused on bringing machine learning and augmented intelligence to the world of operations, development, and security. I believe that this will be far more successful than locking things down and denying access.”

One solution is to use analytics to find evidence of intrusion and damage attempts in a timely way so that you can track it down and block it. 

Ten years ago, enterprises would build a wall to secure themselves against hackers and viruses. They would install perimeter defenses with intrusion detection devices and put scanners on every individual's machine. But today, that tactic doesn’t work. You have so many services that you access outside of your perimeter that it has become porous. One solution is to use analytics to find evidence of intrusion and damage attempts in a timely way so that you can track it down and block it. In the world of software, you need more intelligent tooling to validate and check the work that people do. We have scanners that analyze code looking for vulnerabilities, and you can take action if vulnerabilities are found.

“It’s a different approach. And we’re broadening that security-based approach to the wider application lifecycle management and DevOps area. We can apply machine learning and augmented intelligence to DevOps processes and use the data and intelligence that we gain to predict how code is going to behave in production.”

 Individual responsibility, and education in morals and ethics

To increase the trust they place in their employees, many companies and organizations have formal requirements for staff to undergo annual general ethics and compliance training. But is there also a place for dedicated ethics discussions within the software engineering community?

“If you, as an individual, were asked to do something that's palpably unethical, then you should not do it. Or if you think it’s taking you on the boundary of regulatory issues—I personally have been in situations that took me to the boundary of regulatory issues, and I haven’t had the slightest qualm about going to my boss and raising a flag. But the bigger challenge is whether you would actually know. We see in the press on a regular basis various scandals exposed in different industry sectors, and what is often surprising is how few people actually seemed to know what was going on. If, for example, you’re a humble Python programmer somewhere down in the organization and someone says, 'Hey, we want you to take these numbers and do this analysis on it,’ you may well have no clue as to what the intent of the analysis is."

We should vet the engineers we recruit as best we can, but once they’ve been engaged, give them the freedom to do their job.

“We should encourage people to understand ethics and how it applies to their jobs, and often it’s in ways that they don’t think. Most people, when you give them training on ethics, understand the laws on obvious unethical behavior, such as being offered or offering a bribe, but we need to train more deeply than that."

Practical and actionable insights

Youngjohns has deep yet very practical and actionable insights into how to approach the issue of regulation and trust within the software engineering profession:

  • The global nature of software development and IT today precludes formal, blanket regulation of software engineers.
  • We should vet the engineers we recruit as best we can but, once they’ve been engaged, give them the freedom to do their jobs in the best way that they can.
  • In parallel, we should leverage the power of machine learning and big data analytics to monitor every digital enterprise, not only to make better business decisions, but to protect the business as well.
  • We should invest in deeper education and discussion around ethics and morals as it applies to software engineers and software engineering.

What do you think? Should software engineers be certified? I look forward to reading your thoughts and comments. 

Keep learning

Read more articles about: Enterprise ITIT Ops