“Shouldn’t software engineering be considered a profession?” The question was asked towards the end of a recent conference on software development. It was followed by a little speech that drew murmurs of approval from the audience. The group seemed to agree that software was an important field and that it should be accorded the same status and respect as that given to attorneys and physicians.
I’ve had several conversations on software engineering and how we might transform it into more respected profession. Most of the time, I’ve been talking with fellow software developers who believe that software developers could choose to become a profession. They feel that the IEEE could immediately raise the status of software developers by establishing rigorous standards for software engineers and then creating a test, similar to the bar exam for lawyers, that would separate the sheep from the goats, the software professionals from the pretenders. By restricting the field, software developers would gain power, recognition and social standing,
Such an argument has strong appeal to both software developers and governments. In recent years, the governments of Malaysia and Nigeria have proposed the idea of licensing software developers. Behind these proposals is the idea that a license would increase the prestige of software engineers and encourage more people to become software developers. However, to think that the professionalization of any field will increase the status of the individual members of that field is a mistake.
The concept of professionalization is does not directly address issues of status. As implemented in modern society, it is designed to reduce risk, risk to both the public and to the field itself. Professionalization lowers risk to the public by attempting to eliminate poorly trained individuals. This action not only improves the products of the profession, it allows the profession to reduce the risk to professionals by separating personal failure from the failures of the field.
No professional is able to guarantee that their work will be effective 100% of the time. Doctors see patients die under their care. Lawyers watch clients go to jail. Engineers have seen the failure of bridges and buildings, automobiles and power supplies. In some of these cases, the failure was personal. The professional did not know what to do or didn’t follow the best practices of the field. In other cases, it was not. The professional followed the best practices and knew all that anyone in the field knew. In these latter cases, the profession shields the professional from bearing all of the risk.
Over the history of the computer, we have come to recognize the risks of software systems. Poor software can waste an investment, embarrass a company, destroy a business line, expose confidential data, and finally – when the software is part of a cyber-physical system – it can maim and kill. We have developed ways of identifying and mitigating risks. We have built a large body of knowledge on the subject of risk. We have also found that risk is widespread. Yet we have been unable to make the case that any group of software developers is able to reduce the risk of bad software in a way that deserves the protection of a government. Doctors and lawyers have been able to make this case for themselves. Software engineers have not.
Perhaps the most common way of reducing the risk of software development is through certification. The software community offers a large number of certifications but most of these are directed at the products of specific companies, such as those of Microsoft, Oracle, Cisco or some other firm. Hence they are administered not by a professional body, but by one of the software companies or by a contractor to one of those companies. The IEEE helps administer one certification program, the Professional Engineer Certificate in Software Engineering. However, this program is small in comparison to those for corporate certificates.
The IEEE could do much to improve the quality of the programming community and reduce the risk of software development. However, it seems unlikely that any of these actions would increase the status of the profession. If anything, much of our action seems to be directed to disseminating programming skill more widely and making it more commonplace. We support more programming in STEM classes and support events, like Hour of Code, that encourage programming among the general populace. We also encourage and support non-standard ways of developing programming skill such as open source development projects and open programmer markets.
Of course, neither our efforts to promote programming nor the work of companies to reduce the risk of their products should degrade software engineering. Software engineering is honorable work and has contributed a great deal to modern life. However, we cannot currently make a strong case that software engineers need special licensure and protection from the government, as lawyers and doctors were able to gain in the 19th century.
There may come a time when we can make such a case, when programming skill is so widely shared that we honestly need to know the difference between those who are properly trained in the best practices of the discipline and who are not. Should that time come, we shouldn’t expect an increase in status to accompany it. A reminder can be found in the notices of an influential Washington trade association that refer to the IEEE as the “trade union” for software engineers and suggest that our ideas are created out of narrow self-interest. Such statements are part of the competition for status in Washington. This association knows fully well that the IEEE is not a union under American law. They are just trying to remind us that status doesn’t come by declaring your own importance but by demonstrating it.
