Why society needs a software engineering professional body.

Definition of a Profession:
A profession is a vocation founded upon specialised educational training, the purpose of which is to supply disinterested counsel and service to others, for a direct and definite compensation, wholly apart from expectation of other business gain"[1]. According to the Oxford English Dictionary, professions involve the application of specialised knowledge of a subject, field, or science to fee-paying clientele.[2] It is axiomatic that "professional activity involves systematic knowledge and proficiency."[3] Professions are distinguished from other occupations represented by trade groups due to their level of legal recognition.

Software Development:
Software are applications that run on computer processors that enable the hardware to perform functions. Software development includes all the activities involved in creating software products or systems. These activities may include requirements gathering, design and architecture, actual development, quality assurance and release cycles. I emphasize may as there are IT departments that do things in a very ad-hoc way; I see this a lot in small companies. Although it provides their customers quick turnaround, there are almost always quality issues associated with such ad-hoc releases, and the knowledge is almost always held in one resource, which is not good for the company as a whole.

Software Engineering:
In one sentence, it is the application of engineering principles to software projects. More specifically, it means using a systematic, disciplined and quantifiable approach to managing and executing software projects. This is more normally seen in large corporations, where cross functional teams exist to properly gather requirements and do the technical analyses to provide an estimated delivery date.

Why should software engineering behave as a profession?
The same reason physicians and accountants behave as professionals; their work is not easily understood so ethics and honesty are essential. Unless you study computer science and software development in a distinguished post-secondary institution, it is highly unlikely you will understand the concepts and problems faced by software engineers as they try to build, maintain and deploy complex software systems. Software systems are black boxes to the general masses, and are employed in a variety of critical systems, from life saving medical systems to critical military defense systems. The people who work on these systems must be accountable and honest, else costs could spiral out of control or a life threatening function could be widely released to the general public. Therefore the public is forced to rely on the word of the software engineer as to whether the system was properly tested or not, as they have no way of verifying themselves without using it. If someone’s word must be relied upon, they must uphold themselves to a higher standard and speak nothing but the truth.

Therefore, the only way to encourage (and hopefully guarantee) complete honesty from the software engineer is to treat the role as a profession, with qualifying examinations and a professional body to oversee it. The professional body would manage the qualifying examinations, which would include content to verify the technical concepts a software engineer must possess, as well as the ethics and morals someone in the software field should adhere to. If there was ever a question as to a software engineer’s qualifications or ethics, an organization could file a complaint with the professional body for investigation. If the professional body verified the plaintiff’s accusations, then it could bar the individual from practicing software engineering.

Which software engineering roles should be taken from members of a professional software engineering society?
The software developer, quality assurance and leadership (management) roles should all be members of a professional software engineering society. Accountability is required from these 3 roles to ensure the highest quality software is released, and that honest reporting is delivered to senior management. As I mentioned earlier, in a publishing company in which I was formerly employed, the web solutions manager fabricated his status reports to the executive and provided no transparency to his organization, which resulted in wasteful expenditures and the eventual collapse of the systems he was responsible for in production. If he was a professional, he would at least have the extra fear on his back, though realistically it would still be no guarantee as to whether he would attempt the same deception or not.

What are the drawbacks of a software engineering professional body?
First of all, just because they have a code of ethics does not guarantee all members will follow them. There are many physicians who have violated the Hippocratic oath; however, those that have been caught have been barred from practicing medicine ever again. Therefore, not all the culprits will be caught, but at least several will be rooted out and prevented from causing further damage.

Secondly, a professional body tends to act as a labour union also, so the costs of employing software engineers will go up. This is not a good thing when competing against the cheap information technology labour in India and China. However, given all the product quality concerns recently with imports from China, I think this is a small price to pay. In the long run, with more discipline applied to the software development process, quality will go up and costs will go down. Look at how cheap it is today to purchase a PC which is probably a hundred times more powerful then the 486, which was over $2000 CDN when it first came out in 1990’s. Note that computer hardware architecture and design is done by computer engineers, not computer hardware developers.

Conclusion
With a software engineering professional body there will be oversight on software engineers to reduce dishonest reporting and make the software development lifecycle more transparent, predictable and manageable. These benefits alone make it worthwhile for public corporations to support and sponsor the development of a software engineering professional society. With more manageable software projects, quality will improve and costs will go down, providing benefits to society in general.
Finally, please add your comments. I would be very interested in knowing whether you feel society needs a software engineering professional body or not and why.

Acknowledgements:
1 New Statesman, 21 April 1917, article by the Webbs quoted with approval at paragraph 123 of a report by the UK Competition Commission, dated 8 November 1977, entitled Architects Services (in Chapter 7).
2 Oxford English Dictionary, Second Edition (Oxford University Press, 1989).
3 http://www.ethical-perspectives.be/page.php?LAN=E&FILE=ep_detail&ID=100&TID=909 Asa Kasher, Professional Ethics and Collective Professional Autonomy A Conceptual Analysis, Ethical Perspectives, 12/1 (March - 2005), pp.67-97.
4 a b c Perks, R.W.(1993): Accounting and Society. Chapman & Hall (London); ISBN 0412473305. p.2.

If you can’t load a rifle, don’t be a general.

I firmly believe that technology management should come from within the ranks, not from non-technology areas like sales, finance or marketing. Although this doesn’t seem to be that important a requirement for more generic roles like Operations or Infrastructure leadership, it is an absolute essential for the management of software developers and engineers.

My first example of how a non-technical leader created large problems in an organization is a time when a sales and marketing executive was appointed to the office of CIO (Chief Information Officer). This CIO even told me he had no technical skill and would rely on me for such. Generally, this is acceptable because a CIO’s job is more politics than anything else, except this CIO did not have the technical background to discern who was telling him the truth. This culminated into a huge problem when the CIO began experiencing relationship issues with an employee responsible for the maintenance of the department’s source code control system. Since this employee maintained the system, he was the sole possessor of the source code control administrator’s password. However, when the CIO eventually forced this employee to quit, he was not aware of this password and thus did not secure it before the employee’s departure. A day later, I discovered this mistake but it was too late. The system was no longer manageable and even from the time I left the organization, no solution had been found.

Although the above experience highlights a specific problem created by a non-technical leader, I think the best example of why the general needs to know how to load their own rifle should be drawn from my experiences at another company. The CTO (Chief Technology Officer) didn’t understand technology anymore as he was near retirement, so he hired a young management team to head things up, with me brought in as the manager/lead developer of a smaller unit. Now one of the managers he hired was a consultant who previously worked for smaller companies in senior leadership roles, so the CTO made this manager, who was Director of Web Solutions for 1.5 years, the Director of Development and placed all the application development teams under him, including mine, in order to complete the Documentum implementation for the business. During this time, I discovered that the Director of Development had very basic knowledge of scripting languages and installers, and lacked the technical competence to lead the implementation of a Documentum system. Ends up, this Director lacked the skills to manage the web solutions team he was originally hired for too; this became public knowledge when 6 months later, the company’s main customer web site suddenly began crashing continuously after outsourcing the operations aspect. The President ordered an investigation of technology, which resulted in identifying all the problems to be resulting from the web solutions team. Further examination showed their productivity to be one third that of my department, and that their code produced twice as many production defects as custom applications I was responsible for. It was concluded at an executive meeting that the web solutions team had been completely unmanaged since the Director of Development took over. At this point, the Director of Development and CTO left the company.

I, on the other hand, was an experienced developer and software engineer from EMC (a computer storage company) before taking the leadership role, and therefore was able to read the code and extract the inner workings of the systems on my own, with minimal help from hostile staff. In order to lead my department, I had to replace the original team and keep it running based on my own knowledge. Despite all this, I was three times more productive then the entire web solutions department. Why? I knew how to load my own rifle, so I could pick up the tools and learn the publishing system on my own. Plus, by understanding the internal workings and source code, I was able to successfully identify architectural problems and make releases to fix and/or mitigate those risks, saving myself from the embarrassment of having my production systems crash continually at the data center.

Therefore, I firmly believe in the statement: “If you can’t load a rifle, don’t be a general.”