“You need a license to touch that!”. The case for licensing of individuals within the software engineering profession.

Background

Back in 2004 I completed my BSc Degree in Computer Science at Bradford University; only 20 years after I started. My year in industry got out of hand!

One module I did involved me writing a paper on a legal area concerning computing. I chose to discuss licensing of engineers.

Whilst at the DDDNorth community conference last weekend (Dec 2022) I got chatting on aspects of staff development, problem solving and training with a fellow MVP Matteo Emili and I mentioned this paper I had written. We both thought it might be interesting to revisit it and see if it still held true, best part of 20 years on.

So enjoy, remembering this was originally written 18 years ago…

Introduction

Throughout the history of science and technology there has been a trend in the development spectrum away from the gentleman amateur and towards the professional engineer. This report explores at which point on this spectrum Software Engineering currently lies and, if it is found to lie at the fully professional end, whether or not there is a need for licenses to practice.

Software Engineering Professionalism

Computing in general, and software engineering in particular, is a young discipline. Its professional societies are only around 50 years old, the BCS was formed in 1957; it is now only reaching a point where it is not uncommon that when retiring, practitioners have had their whole career in the field.

Due to this relative youth the formal call for professionalisation is only recently being brought to the fore. This is not to say that people working in computing have not had the need to be professional - this has always been important - but since the mid 1990s, there has been serious talk of some formality, maybe even of a license to practice, as in other professions. This debate can be seen at least as a sign of puberty, if not one of maturity, for the industry.

What are the Real Benefits of Licensing?

The key factor behind any call to licensing is one of public confidence. The license to practice provides a standard by which the purchaser of any service can see that a practitioner has met a minimum level of competence. This does not mean that they are a good Doctor or Accountant, bad practitioners still exist, but, if they do not maintain this standard, there are processes through which their license may be revoked.

Perception of the Computing Industry

Currently such a position of public confidence is not enjoyed by the computing industry. The media coverage is usually concentrated on perceived-failing systems, such as the Swanwick Air Traffic Control Centre and the new NPfIT NHS records project (even before the project has really started). The media does not talk of computing success, it is not newsworthy.

This media slant is not unsurprising, given the project success rates shown in Figure 1. If this were figures in the Civil Engineering industry, would anyone be crossing bridges?

In fact, the route to licensing of Civil Engineering came from failing constructions such as bridges. Canadian engineering folk law [SM99a] has it that the iron used to make the rings given to graduating engineers comes from the collapsed Quebec City Bridge of 1907, as a reminder of their public duty. Licensing of engineers in Texas came about after a boiler explosion that killed 300 school children [SM99a].

Another factor in the perception of computing in many people’s eyes is that they say ‘I have a computer and use it OK, so how hard can this software thing be?’

This viewpoint is not limited to the ‘man in the street’, but also to many corporate managers.

A figure regularly reported at Microsoft conferences is that 70% of corporate development is done using the Visual Basic family of languages, commonly not by specialist programmers but by end users. These users have little knowledge of software engineering principles, and hence often produce initially functional but poorly maintainable or un-scalable systems. It is often the reliability of these systems that shape public perception of computing.

Is there need for universal licensing?

Given these facts, would requiring all IT professionals to have a license be the right move? The answer has to be no.

Discipline	Licensed
Civil	44%
Mechanical	23%
Electrical	9%
Chemical	8%
All Engineering	18%

Table 1: Percentage of licensed Engineering graduates in the US as of 1996 [SM99a]

In other engineering professions only a small percentage of people are licensed [Table 1]. The remainder of the workforce are working towards licensing, or are responsible to a licensed engineer.

Given this data Steve McConnell suggest only 5-10% of software engineers need to be licensed, specifically those working on safety-critical systems [SM99b].

A Move to Licensing

In 1999 the Texas Society for Professional Engineers passed a resolution to license Software Engineers [LHW99]. The scheme was based on applicants providing nine references and meeting one of the following criteria:

• 16 years’ engineering experience
• 12 years’ engineering experience, plus a bachelor’s degree from an accredited program.
• 6 years’ engineering experience, plus a PhD in engineering or related subject from a university with an accredited undergraduate program.

In June 2001 the Canadian Engineering Accreditation Board (CEAB) accredited three degree programs [DLP02a] and instigated a licensing program with similar requirements to that in Texas.

The Current BCS Position

Currently there is no plan to license Software Engineers in the UK or the EU, only voluntary professional schemes are in place.

Historically the BCS had a membership system which provided a means to get an Engineering Council Charter Engineer (CEng) qualification. In 2002 the BCS underwent a radical restructure to provide a more outward-looking system in an aim to promote professionalism in the industry. The major change in the membership system was a new grade of Chartered Information Technology Professional (MBCS CITP) that sits along side the CEng qualification.

Initial results seem to show that the changes have been approved by the industry as ‘The British Computer Society has reported a 200% leap in membership applications since the launch of its new grading structure, - reports chief executive David Clarke’ [BCS04a]

There has also been a change in the culture at the BCS. At the West Yorkshire BCS branch AGM (25th May 2004) David Clarke the Chief Executive of the BCS gave an example of how, when he joined the BCS, there was no standard way for the public to ask it questions; they had been asked by a national newspaper for comments on the Home Secretary’s proposed ID card scheme. It had taken three weeks for his team to find a person willing to speak on the subject. Changes to the BCS now see it taking a more active role in advising bodies such as government committees on IT related issues [BCS04b]. This is a key area that a professional organisation must address in the current media-centric world.

For the foreseeable future the BCS is not making moves toward licensing, preferring certification based on internationally recognised products that it provides such as European Computer Driving License (ECDL) and the European Certification for IT Professionals (EUCIP).

Certification as an alternative

Usually certification is not compulsory, unlike licensing, and is often vendor-led. Other than the BCS, the major certification schemes are from vendors such as Microsoft, Cisco and Novell. Certification is well established, and aims to give all parties benefits; the customer knows the engineer has been trained, the vendor reduces their support calls due to engineer training, and the engineer gets a way to differentiate themselves from their competitors.

The problem is that such qualifications age rapidly - usually re-certification is required every 3 to 5 years as vendor products are dropped and new ones replace them. Also, some of the qualifications have become devalued due to ‘boot camps’ and ‘brain-dumps’ , passing the certification exams is often dependant on the students budget and ability to cram, not their fundamental knowledge of the subject.

Certification is a valuable tool to the industry, providing good specific product training, but not a replacement for good basic grounding provided by a degree or similar.

Has licensing worked thus far?

A view on the success or failure of licensing can be found in the ‘Communications of ACM’ [KK02]

“…after four years, what has been the overall impact of software engineering licensing in Texas? In our view, the news is good: licensing had practically no effect…”

The key factor cited in reviews of the state of licensing is the lack of a stable core of knowledge that a practitioner is required to study [KK02] [DLP02b]. In other engineering disciplines there is a well defined boundary between research science and engineering. For example if you wished to make TVs for the consumer market you could hire a physicist; they could make you a TV, but it would no doubt be expensive, unreliable but revolutionary. The normal practice would be to hire experienced electronics and production engineers, who would draw on the core knowledge of their fields, originated by research scientists, to make a suitable specified product on time and on budget.

Are we tackling the right problem?

An interesting point of view is put forward by Pete McBreen in ‘Software Craftsmanship’, this again states the problems with lack of a stable core of knowledge, but highlights that ‘The concept of a single, responsible engineer signing off a complete work is not feasible for software’. [PM02a]. Software projects are just too large and complex and, unlike Civil Engineering building codes, there is no agreed legal standard to sign off against anyway.

McBreen goes on to propose that Software Engineering, not just licensing, fails not because of the lack of experience or skill, but due to the lack of personal responsibility. He argues that it is better to have a master-apprentice approach to software development, with a senior programmer taking juniors under their wing for a number of years, with their systems being developed and handed on like a prize heirloom - the EMACS product is held up as an example [PM02b].

This structure has its appeal. It seems to fit well with other professions, and while they may not be called master and apprentice similar structures occur in the legal, medical and accountancy professions. Though, interestingly, they appear less frequently in traditional engineering, where in many ways the personal craftsman’s responsibility has been replaced by a corporate regulation framework.

Is Licensing Round the Corner?

Software engineering is not ready for universal licensing, the core body of knowledge is still growing too fast to allow any true foundation engineering degrees to be stabilised. It could reasonably be argued that this stabilisation may never occur, the rate of technology change and tre ihe huge variety of projects for which software is developed may defeat all efforts for universal standards for licensing. However, this does not mean that licensing may not appear in specialised areas, if they can be formalised to a sufficient degree. The most likely area is safety-critical systems.

In general, for the foreseeable future the industry will have to rely on voluntary membership of organisations such as the BCS and vendor certifications. This in effect means that the onus of good practice and professionalism falls, as always, on the shoulders of the individual. Maybe what is required is the personal responsibility of the gentleman amateur and craftsman to build the confidence of the general public rightly expects.

.. And 18 years on

So what has changed 18 years on, well not a lot that I can see. There is no clamour for licensing, our media only cover stories of failure, and projects of all sizes are still failing.

There is still no agreement on best practice, at least to the level required for licensing. IT is still just too fast moving, another week another framework, language or pattern.

We as individuals and teams are still, and always will be, responsible for our own actions, and we still have to strive to deliver high quality solutions that meet our client business needs.

What are the chances of a change in the next 20 years? Or will it become an irrelevance as we move to the use of more AI tools?

Maybe I will come back to this post around 2043 and see what has changed.

References

Code	Details
BCS04a	BCS Press Releases, “New BCS Membership Campaign Results in 200% Application Rise”, 20 September 2004
BCS04b	“Identity Cards”, BCS News Jan 2004 “Response from the British Computer Society regarding the call for statements to House of Commons Home Affairs Committee enquiry into Identity Cards”ResponseJan2004.htm
DLP02a	P96 “Licensing software engineers in Canada”: David Lorge Pamas, “Communications of the ACM” Volume 45 Issue 11 November 2002, ACM Digital Library
DLP02b	P98 “Licensing software engineers in Canada”: David Lorge Pamas, “Communications of the ACM” Volume 45 Issue 11 November 2002, ACM Digital Library
KK02	P95 “A Rice University perspective on software engineering licensing”: Ken Kennedy and Moshe Y. Vardi, “Communications of the ACM” Volume 45 Issue 11 November 2002, ACM Digital Library
LHW99	P27 “Licensing software professionals: where are we?”: Laurie Honour Werth “The proceedings of the thirtieth SIGCSE technical symposium on Computer science education”, 1999 ACM Digital Library
PM02a	P40 “Licensing is an attempt to solve the wrong problem”: Pete McBreen “Software Craftsmanship: The new imperative”, Addison Wesley 2002
PM02b	P66 “Being the Maintainer of an Application is a High-Status Position”: Pete McBreen “Software Craftsmanship: The new imperative”, Addison Wesley 2002
RL04	ARC220 - Slide 6, Rafel Lukawiecki, “New Developments in Microsoft Solutions Framework”, Microsoft TechEd Europe 2004 Post Conference DVD
SM99a	P56 “Need for Engineering”: Steve McConnell, “After the gold rush, creating a true profession of software engineering”, Microsoft Press 1999
SM99b	P103-104 “Stinking Badges, Licensing” : Steve McConnell, “After the gold rush, creating a true profession of software engineering”, Microsoft Press 1999