Does South Africa need professional Software Engineers?
by Prof Barry Dwolatzky
Professional Engineers are formally recognised in terms of South African law. We have Electrical Engineers, Chemical Engineers, Civil Engineers and other branches of Professional Engineering. Should we have professional “Software Engineers”?
First the legal stuff: Back in 1990 parliament passed the “Engineering Profession of South Africa Act” [Act 114 of 1990]. This gave rise to a statutory body that became the “Engineering Council of South Africa”, or ECSA, under the later “Engineering Profession Act, 2000”, [Act 46 of 2000]. ECSA is responsible for “promoting a high level of education and training of practitioners in the engineering profession so as to facilitate full recognition of professionalism in the engineering profession, both locally and abroad.” [ECSA website www.ecsa.co.za ] In practical terms ECSA accredits engineering educational programs, manages the registration of professionals, and promotes the interest of practitioners and the profession.
Should “Software Engineering” become a branch of engineering under the ECSA framework? I believe it should!
I feel that there is a strong need for formal recognition of Software Engineering as a profession alongside other engineering disciplines in South Africa. Software is an increasingly critical component in many systems. Software projects attract large budgets and require professional management. Some of these projects also have huge social and commercial impact.
I think that Software Engineering should become a formal branch of engineering for the same reasons that parliament saw fit to bring other branches of Engineering under ECSA and the terms of the Engineering Profession Act.
Having said this, however, there are numerous very difficult issues to resolve. Some of these are:
- Which body represents the interests of software professionals? Each of the existing branches of engineering has a professional body – an Institute or Association – that organises and represents its members. ECSA in most cases works with these national bodies. The South African Institute of Electrical Engineers (SAIEE) probably has the strongest claim to representing engineers engaged in “software engineering”. But there are other bodies, such as the Computer Society of South Africa (CSSA) that may claim “representation rights”. Should a new Institute be established?
- What would the accredited education of a software engineer look like? There have been several international efforts to establish a curriculum for Software Engineering Education (the IEEE and ACM are international professional organisation that have published software engineering curricula) and a “software engineering body of knowledge”, or SWEBOK (see www.swebok.org )
- Would all software developers and related professionals be required to register?
- What about those hundreds of thousands of South Africans currently employed in the software industry? Would they also need to satisfy the formal prerequisites for professional registration?
- Is “software engineering” actually an engineering activity at all? Some would argue that it isn’t.
I’m throwing out these thoughts in the hope of generating some debate on this topic. I have my own views which I will share in further postings on this blog. Much of what we are doing through the Joburg Centre for Software Engineering (JCSE) at Wits University aims to promote a professional engineering approach to software development.
What are your thoughts?
17 Replies to “Does South Africa need professional Software Engineers?”
Comments are closed.
Contentious topic. For me the most important point is to determine if software engineering is an engineering dicipline. I believe it SHOULD be, but currently COULD NOT be.
Perhaps someone with more experience in these fields could clarify, but my understanding of the other engineering fields (electrical, chemical, civil, etc) is that they do not move at the same pace as software engineering does.
Not to say that these diciplines don’t evolve, just not at the pace of software and not with as often a fundamental shift in the core of the dicipline. BUilding for the web is fundamentally different to building for the desktop is fundamentally different to building for the phone. It would be synonymous to civil engineers having to suddenly understand how to build houses in an environment with an increased gravitational force.
Setting up software as an engineering dicipline is probably the first step to getting it to act like one, given its age it makes sense. The question is, can these institutions keep up? and who would listen?
Software thrives on its independence from authority, of course this is also why it is filled with trial and error.
I agree in most parts with the previous comment written by Marc Walter [July 26, 2010, 8:53am].
Before SE can be legally enshrined as an “engineering discipline”, it has (yet) to become an engineering discipline practically as a matter of fact. As Tom Maibaum has pointed out not long ago (at the conference ICFEM-2008), the classical engineering disciplines are typically characterized by:
* a high level of standardisation, and
* the availability of readily applicable “handbook knowledge” (on the basis of standardisation).
In software engineering this (i.e.: high level of standardisation plus “handbook knowlege” as outlined by Maibaum) is currently not the case, as a matter of fact. Whether or not this can or should become the case in the future is still a topic of ongoing discussions. Within those discussions, at which I often participated, I have encountered the following three basic positions so far:
– Position 1)
“It is not possible to reach a high level of standardisation and handbook knowlede in SE”, consequence: SE /can/ not become a normal engineering discipline (as a matter of principle), consequently there is no question (at all) of any legal recogniction of SE as a registered profession.
– Position 2)
“It might be possible to reach a high level of standardisation and handbook knowledge, but we would not want this”, in other words: SE /should/ not become a normal engineering discipline, consequently the possibility of legal recognition of SE as a registered profession should be (voluntarily) rejected.
– Position 3)
“It is possible to reach a high level of standardisation and handbook knowledge in SE, and we want to work towards this goal”, on other words: SE /can/ and /should/ become a normal engineering discipline; consequently also the legal recognition of SE as a registered profession should be achieved one day in the future.
Those three positions mark a triangular space of discourse in which further discussions unfold themselves in all details.
In this context let me point out that there exist already 3 (sub-)domains within software engineering in which we have already achieved a reasonably high level of standardisation and applicable handbook knowledge. These are:
* Relational Database construction,
* Compiler construction,
* Operating Systems construction.
Those three can nowadays rightly be regarded as “standard problems” to which fairly standardized construction solutions are known.
But then, unfortunately, these three success stories of SE were then taken OUT of the SE curriculum (for whatever reason), such that it appears to us now as if Relational Databases, Compilers and Operating Systems would have nothing to do with SE any longer. Consequently it appears to us as if SE would forever continue to struggle with non-standard solutions to non-standard problems: Consequently, on the basis of such an observation, we find Positon 1 and Position 2 (see above) in the discussion: Those two positions typically concur with the characterisation of SE as an “ART” or as a “CRAFT” – in contrast to SE as “Engineering”.
Consequently those people, who choose to maintain Position 3 (see above) in the discussion, should hint at those 3 types of success stories (Databases, Compilers, Operating Systems construction) of standardisation in SE, and they should continue to search into such a direction. Such a search would also entail a finer classification of TYPES of software systems, to which methodological standardisation would then eventually become applicable.
> Should “Software Engineering” become a branch of engineering under the ECSA framework? I believe it should!
First off I was a Software Engineering Major way back in the day and have been working in the IT field for 10 years.
Over my 10 years I have been on numerous projects, some very successful and others not so. In my experience , if ‘Software Engineers’ built bridges , there would be a lot of broken bridges.
Reason : Developers learn while they code production systems because the technology changes to fast , an Engineer would never do this. The bridge would fall down.
It’s a sad truth, but it is one that needs to be realized. It is also not just a South African thing.
In life you need to recognize your weaknesses before you can start fixing them. It does not mean that South Africa does not need professional software engineers. We actually need them desperately.
>> I think that Software Engineering should become a formal branch of engineering for the same reasons …
Maybe we are dealing with multiple questions here. Amongst them:
1) Should ICT staff be labelled as “professionals”, and be managed as professionals regarding accountability for quality and delivery? Definitely.
2) Are all ICT staff “engineers”? Definitely not. Software development does not stand isolated any more. It shares a “professional” side with project managers, Business Analysts, Testing experts and others who all contribute to a single delivery, of which we can measure the “quality”. Even “Software Engineers” have to deal with Agile development approaches, where the customer is central in the project team. All of these lend a “soft” or “human” aspect to Software Engineering, that may transcend the original meaning of “Engineering”.
Can we rephrase as follows?: “I think that all ICT staff, including software engineers, should be professionals…”
I would like add on position 1 and position 2 on Stefan’s comment above. I’m looking at things on the point of view of an Embedded developer, which is hugely software development than simply electronics.
In a article by Peter Denning and Richard Riehle – “Is Software Engineering Really Engineering?” the authors wonder if software development is indeed an engineering discipline. They contend that other branches of engineering use standardized tools and metrics to produce systems with predictable outcomes.
This is what they say about software: “[no process] consistently delivers reliable, dependable, and affordable software systems. Approximately one-third of software projects fail to deliver anything, and another third deliver something workable but not satisfactory.”
That huge failure rate is indeed sobering, but no other discipline produces systems of such enormous complexity. And we start from nothing. A million lines of code represents a staggering number of decisions, paths, and interactions. Mechanical and electrical engineers have big catalogs of standard parts they recycle into their creations. But our customers demand unique products that often cannot be created using any significant number of standard components.
Most developers cannot use a particular software component (comm stack, RTOS etc.) because, well, how can they trust it? One wonders if 18th century engineers used the same argument to justify fabricating their own bolts and other components. It wasn’t until the idea of interchangeable parts arrived that engineering evolved into a profession where one designer could benefit from another’s work.
Today, mechanical engineers buy trusted components. A particular type of bolt has been tested to some standard of hardness, strength, durability and other factors.
In safety-critical applications those standard components are subjected to more strenuous requirements. A bolt may be accompanied by a stack of paperwork testifying to its provenance and suitability for the job at hand. Engineers use standardized ways to validate parts. The issue of “trust” is mostly removed.
Software engineering does have a certain amount of validated code. For instance, Micrium, Green Hills and others offer products certified or at least certifiable to various standards. Like the bolts used in avionics, these certifications don’t guarantee perfection, but they do remove an enormous amount of uncertainty.
I’m sure it’s hugely expensive to validate a bolt or other mechanical components. And the expense of validating software components is also astronomical. And on top of this we add a burning issue of open souce software!
I would advocate for the recognition of Software Engineering as a Professional Engineering discipline including its regulation.
As someone who wants to distinguish my work from amateurs and ‘fly-by-nighters’, this would be the right way.
However both the public and customers will need to demand it for it to gain real traction in my opinion.
The implication of liability is a whole debate on its own due to the bad track record our industry has (as highlighted by the other posters).
Canada has taken the lead in showing that SE can be regulated, so why should we want to be late adopters.
On the issue of who should represent SE at ECSA: This might be regarded as a political mine field but, I would probably think that both SAIEE and CSSA contain SE people. The question is whether either will be able to realise that SE can function in its own right, doing so without excluding people with the ‘wrong’ education during the bootstrap phase of being recognised. Thus maybe a new entity would be better to accomodate the overlap. There are people who are highly professional through a self-taught approach, and those with Computer Science or Engineering degrees. Practising SE should have the ability to get certified regardless of their background while we transition into a recognised state.
Definately why not??
Wikipedia defines a engineer as follows:
“Engineering is the discipline, art and profession of acquiring and applying technical, scientific, and mathematical knowledge to design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective or invention.”
Software engineer therefore also falls into the parameters of the above definition. However, it is of utmost importance that the profession be regulated with regard to registration. In my opinion not regulating the industry of software enginering and associated occupations kleads exactly to giving the industry a undesired bad publicity
There has long been a debate between the statutory professionals and the non-statutory ones. It is entirely understandable that a professional body should jealously guard its revocable designations that confer a right to practice on its members. Is there an absolute dividing line between them and the rest?
SAQA is about to enter the debate, as it moves towards complying with the NQF Act, which requires SAQA to recognise professional bodies and to register professional designations.
The Computer Society of South Africa (CSSA) is non-statutory and currently has one designation which would be registered with SAQA, that of PMCSSA (Professional grade Member). This designation does not differentiate between knowledge areas, encompassing programmers, engineers, lecturers and managers, to name only a few.
Is this sufficient recognition for a software engineer?
I believe Software Engineering should be a recognized discipline, but I also believe that a significant proportion of software development is not engineering. The best outcome to my mind would be to at the very least have a distinction between
1. software that is applied in traditional electrical engineering fields, such as automotive, aerospace, military and telecoms where there are significant standards defined that are of an engineering origin and quite often address embedded environments
2. software that is applied in “pure” computing fields, typically referred to application development where the standards are of a more evolutionary and dynamic nature
I come for the former field and have generally found that “Software Engineering” meetings, such as the ICSE have moved very far away from having any sense of what is happening in field 1. My preference would be to define two professional streams with the proponents being referred to as:
1. Software Engineer, and
2. Software Developer
Typically you would find Software Engineers have a Electrical Engineering degree, while Software Developers would more than likely have a B.Sc or B.Com Informatics/Computer science degree.
This has been one of my pet peeves for some time so I am very glad for the debate.
I think just like in other professions where e.g. nurses and clinical assistants are held to a different set of standards than General Practitioners, Surgeons or other specialists for that matter, the same distinction needs to be made in our field. There is however a firm regulation in place that at least one professional with the correct credentials should be in control and ultimately responsible for the body of work being performed.
A complete lack of control such as we have currently is unprofessional per se, and until we have this in place all IT work will likely be deemed not to be of a professional nature.
I have also previously suggested that we put pressure on ECSA who incidentally has software engineering as one of their classified professions, yet have no regulations or voluntary associations in place to govern the field.
Since the statutory part is in place within ECSA this makes sense on some level, the only problem to overcome being the connection between the voluntary and statutory bodies. A complete lack of interest on this from the ECSA side, to the point where they have stated in their strategic plan that it is their goal not to assume responsibility over any additional areas of expertise, has made me realize that this is perhaps beating a dead horse to start with.
A friend of mine asked me last week when I think Software Engineering will become mature, and my response was that sadly from what I can see that is not the direction we are currently moving in. Reading things like this may yet give me reason to change my mind!
I’ve tried to capture some of the threads coming out of this discussion in another posting: “Some further thoughts on the professionalisation of the SA ICT Sector” …. I’ve also created an opinion poll at the end of that new posting. Click over to the new posting to see where this conversation leads us.
I agree – It should.
If we want to be fully regarded and paid as professionals then we should be such a body.
I am a software engineer and I believe it should be regarded.
I think people easily confuse software engineering with software development which is an indication of the sad state of software engineering projects in SA. There are plenty of standards available that defines a software *engineering* project as opposed to a software development project. Examples of software engineering would be a IEC60730 Class B compliant real time system for the control of a household appliance or other systems where deterministic execution is an absolute necessity. Project costs are typically measured in thousands of rands per line of code and is always accompanied by formalized documentation specifying exact behavior. I.e. the engineer responsible can sign his/her name with confidence to the project and moreover can be held liable for any serious design or implementation deficiencies i.e. in case of death or injury to users of the product. Software development however centers around services provided to complete projects with inexact and or flexible specification. The client has less strenuous requirements but also at a fraction of the cost. I’m quite certain that very few companies in S.A. would be able to afford, never mind implement, a software engineering project to the applicable international standards and that is where the problem lies. There are few products originating in SA where such standards are required and therefore the skills base especially amongst computer science graduates is very shallow with regards to engineering. I think calling yourself a professional engineer because you’ve written a few web apps is a bit of a stretch.
I think it should not be part of engineering. Im a programmer my self and If I ever got any formal training from a university etc I would be so far behind. Programming evolves so much faster and formal institutions would not be able to keep up. How can you give someone a degree in one set of rules then 5 years later the scope has changes so much that its not valid anymore. Also people would probably love to be called software engineers and that would water down all programmers and make weak ones. The web is moving closer and closer to a dominant development standard for mobile app development and also desktop software. So … , things are changing so fast, i dont thing any one can keep up
There are so many views regarding this topic and there are still more individuals having their neither valid nor invalid hypothesis regarding this topic, the focus should rather be towards identifying why software engineering is not a branch of engineering under the ECSA framework.
I agree with Christiaan on the distinction between software development and engineering. I also strongly believe that we need more software engineering skills in software development.