IET
Decrease font size
Increase font size
Topic Title: Engineer Status in UK
Topic Summary:
Created On: 19 December 2012 03:07 PM
Status: Read Only
Linear : Threading : Single : Branch
<< 1 2 3 Previous Last unread
Search Topic Search Topic
Topic Tools Topic Tools
View similar topics View similar topics
View topic in raw text format. Print this topic.
 15 April 2013 10:36 PM
User is offline View Users Profile Print this message



westonpa

Posts: 1771
Joined: 10 October 2007

Of course there is much truth in what you suggest about many lecturers but equally there are many who have much experience of the real world. I prefer the team work approach where we use the best of all our skills to arrive at the best solution and I conclude that both those in industry and those in university have their part to play. I think a good combination of qualifications and work experience makes for a better engineer.

Regards.
 20 April 2013 03:05 PM
User is offline View Users Profile Print this message



jencam

Posts: 608
Joined: 06 May 2007

I think that more precise answers to the questions concerning competency will be generated if specific, but regularly occurring, scenarios in engineering are examined.

The first scenario is developing software for safety critical embedded systems in the civilian world - such as medical infusion devices or anti-lock brakes - where a bug in the software could result in a fatal accident. Do any recognised courses and qualifications in developing software for safety critical embedded systems exist that will demonstrate to an employer that the software engineer meets a certain minimum level of competency? You could bang on about using Ada or MISRA C but even the best tools does not make its user competent. Something to also take into account is that bugs in software often lie undetected for many years. Memory leaks are a particularly insidious problem because software failure tends to only happen after software has been running for prolonged periods, including several months. This effectively has the potential to negate time served in industry as a measure of level of competence. It is quite possible that the original software engineer could have left the company long before a disaster resulting from his programming errors finally happens. If he has landed a senior position in another company then should he be forced to resign on the basis that he isn't competent?

Some time ago my son came across an American article about competency in software engineering. The article stated that it was acceptable for software engineers who work in business IT and web design not to have any specific formal qualifications but legislation must be imposed that those who develop code for embedded systems must hold a recognised degree. It's difficult to tell whether the author subscribes to academic snobbery or lacks understanding of how universities actually teach embedded systems. Investigations by my son have revealed that the microprocessor and embedded systems course taught in many British universities is almost the same as that in the electronics A Level. It just teaches the basics and involves a simple project. Very rarely does the course include more sophisticated development tools like debuggers or code profilers. Therefore holding a degree certainly does not indicate that its holder is competent to develop embedded software any more than a person who just holds an A Level is. Microcontrollers and their development tools are now inexpensive and readily available to any Tom Dick or Harry, which has created an explosion in the number of people with the ability to develop software for embedded systems. How exactly can a line be drawn between competent software engineers and software cowboys?
 21 April 2013 01:51 PM
User is offline View Users Profile Print this message



westonpa

Posts: 1771
Joined: 10 October 2007

Originally posted by: jencam
I think that more precise answers to the questions concerning competency will be generated if specific, but regularly occurring, scenarios in engineering are examined.

Good luck with that one then. The world of engineering changes in every second of every day and the differences between 10 years ago and today are huge. Some principles of course remain the same but developments of course move on. I agree that your approach will lead to an improved understanding of competency, and that should always be sought, but I conclude that precise answers will not be found, which cover the entire area of competency, because they will only be precise for the particular problem they seek to address and competency is much larger and wider than that. Competency changes with the person and with the area in which the competency is required and with the technology of the time and with the particular variables involved in the item being worked upon and with the knowledge which is available at the time, and so on.
The first scenario is developing software for safety critical embedded systems in the civilian world - such as medical infusion devices or anti-lock brakes - where a bug in the software could result in a fatal accident.

And so it would be better to have the work checked by a second competent software engineer and also try to test it thoroughly etc., in order to minimise the risks. The next thing would be to put systems in place to pick up the issue quickly and then respond to it quickly and in the correct way. You speak about your son a lot, do you let him drive a car knowing that he could crash and die or did you take him out in your own car knowing that it was possible you could crash and die? How did you assess your/his competency? Did you ever have a 'near miss'? If you did, did you then book yourself onto a training course to improve your competency or else did you just carry on and try to be more careful based on your experience? I let my son drive and also I have had a few accidents and near misses and also been on the receiving end as well. Life has risks involved and mistakes will always be made and whether a person(s) is competent or not depends on the circumstances at the time. As I worked for Siemens in software commissioning I do know a little about software and I can assure you that no matter how competent someone is they will never iron out all the bugs because the human brain/mind cannot hold within it the entire complex program and run every possible scenario and also interface that with every possible scenario of hardware failure and every possible scenario of changes made by humans etc. We have to put in place systems for rigorous testing and then systems to pick up issues and which provide feedback which is used to make improvements.
Do any recognised courses and qualifications in developing software for safety critical embedded systems exist that will demonstrate to an employer that the software engineer meets a certain minimum level of competency? You could bang on about using Ada or MISRA C but even the best tools does not make its user competent.

I will not bang on about anything because I am always in favour of improving education, particularly in the areas of safety.
Something to also take into account is that bugs in software often lie undetected for many years. Memory leaks are a particularly insidious problem because software failure tends to only happen after software has been running for prolonged periods, including several months.

Correct, I have seen bugs come into play after a 5 year period and when fixing those bugs, which we only became aware of because they caused an issue, I concluded that maybe God could have spotted it at the time when the software was written, but then if we look to nature I am not quite so sure because I have also seen a few bugs there as well, and that has been developed over billions of years.
This effectively has the potential to negate time served in industry as a measure of level of competence. It is quite possible that the original software engineer could have left the company long before a disaster resulting from his programming errors finally happens. If he has landed a senior position in another company then should he be forced to resign on the basis that he isn't competent?

Maybe you are not aware of all the laws which exist with regards to health and safety, both statute and civil, but if a person is found to have been negligent and this led to a negative outcome then there is enough law already in place to take appropriate action. But the question then comes down to was that failure caused by someone's negligence and that would be decided by 'experts' in the relevant field and the relevant judge etc. Generally if the person was incompetent the 'experts' will easily arrive that decision however it is not always so simple. Let us say that the sofwtare engineer was asked to write a reasonably large program for some safety critical device/equipment and sometime later a bug was found and which had caused a fatality. Was it the software engineers fault or was it the lack of testing? Who is then responsible for the testing, the software engineer or other people in the company who maybe assign a budget to the project? Should it have been tested better on site? Was there maybe an issue sometime before which did not cause a fatality but went unreported due to some other reason? Etc., etc., etc. Was the software engineer actually the best person for that job or was he/she the low cost version who was prepaired to work the long hours? Was that bit of software code written at the end of a 14 hour shift or just after someone walked into the room and started talking about the next project and so disturbed the concentration of the engineer?

Just maybe there were several people who were not performing at their best and which led to the fatality.

Some time ago my son came across an American article about competency in software engineering. The article stated that it was acceptable for software engineers who work in business IT and web design not to have any specific formal qualifications but legislation must be imposed that those who develop code for embedded systems must hold a recognised degree. It's difficult to tell whether the author subscribes to academic snobbery or lacks understanding of how universities actually teach embedded systems.

Maybe the author subscribes to the principle that the relevant people should be taught to degree level on a good quality course but is not the person who is actually going to go out and design each and every course. In a team approach each part of the team has to peform.
Investigations by my son have revealed that the microprocessor and embedded systems course taught in many British universities is almost the same as that in the electronics A Level. It just teaches the basics and involves a simple project. Very rarely does the course include more sophisticated development tools like debuggers or code profilers. Therefore holding a degree certainly does not indicate that its holder is competent to develop embedded software any more than a person who just holds an A Level is.

But holding the degree does prove that a person can learn and digest and use information to that level. Not holding the degree does not of course prove that a person cannot but in this case we would need to find another way to assess competency. I conclude that all courses could be improved with regards to the safety aspects so I will not disagree with the point you are trying to make but you and I are the 'older' generation and we are more responsible for today's education system than is your son or my son and so maybe if the relevant courses are not as they should be then we should take some of the blame and try to improve the situation.
Microcontrollers and their development tools are now inexpensive and readily available to any Tom Dick or Harry, which has created an explosion in the number of people with the ability to develop software for embedded systems.

True, but not every Tom, Dick and Harry goes down to Maplin and then buys a cheap MP and then programs it and then sticks it into the safety critical systems of a Boing 747. As you probably just saw a couple of guys bombed the Boston marathon and a company in Texas were holding 100's of times more Ammonia than was allowed by USA law, without proper notification such that authorities could then make the proper checks on safeguards, and this all goes to show that regardless of all the checks which are put in place, if some people do not wish to comply then there will be negative consequences. All we can do is learn from it and put in place systems to ensure this is the case so that we minimise future risks.
How exactly can a line be drawn between competent software engineers and software cowboys?

When we employ a software engineer then we can check their qualifications and previous experience and then also check their work whilst they are working for the business and in addition we can put in place other systems to ensure secondary checks on that work and systems to ensure that out in the field errors are quickly picked up and addressed and new learnings are fed back to make improvements. Thereafter if a person is found to be incompetent then take them through the disciplinary procedures if it cannot be solved by more training, supervision, reassignment, etc. I think one of the big issues is that if one company sacks somebody because they were incompetent then they are unable to convey that message to the next employer. That is not an easy one to solve because of course some employers may not be correct in that assessment and the new job may be slightly different.

Regards.

Edited: 21 April 2013 at 01:59 PM by westonpa
 23 April 2013 05:42 PM
User is offline View Users Profile Print this message



jcm256

Posts: 1792
Joined: 01 April 2006

A few years ago, a proposal was that "Engineer Surveyor" was to become a protected title; not that high of qualification needed to become one but as usual came to nothing. There is no reason why those that do a specialist job in engineering cannot have a protected title, with that specialist discipline put in front of the word "Engineer".
Something like they do not that many miles away in Ireland




the Association of Building Engineers (ABE) is a leading body for professionals specialising in the design, construction, evaluation and maintenance of building construction.
The Association has a proven track record of serving professionals, the public, and the industry, and both the organisation and its members provide quality services whilst maintaining a personal approach. In the UK there is no legal protection of the title 'Building Engineer',' Building Surveyor', or 'Quantity Surveyor', however in the Republic of Ireland legislation does protect the titles 'Building Surveyor' and 'Quantity Surveyor' and membership of the ABE is acknowledged in the legislation as meeting the requirements to register to use these titles.

Qualified members of the ABE are recognised by the Council of Mortgage lenders as being able to issue certificates and valuations in relation to properties for lending purposes. The wider recognition of the Association means that members are able to qualify as 'Chartered Environmentalists', register as 'European Building Experts' and will shortly be able to register as 'Chartered Engineers', all of which is possible because the ABE standards of membership and level of competency required by members has been assessed by organisations such as the Engineering Council and Society for the Environment and it has been concluded that the standards required are at least equivalent to other professional organisations working in the sector.


Like they do in America.
http://www.bpelsg.ca.gov/consumers/bpelscmf.pdf

https://en.wikipedia.org/wiki/Regulation_and_licensure_in_engineering
 23 April 2013 06:07 PM
User is offline View Users Profile Print this message



amillar

Posts: 1918
Joined: 28 May 2002

I'd basically second all the above. In addition, the fundamental point is that safety-critical software systems to IEC 61508 (or derived standards such as EN 50128 that we work to) do not assume that safety is achieved by using trained and competent software engineers. Because all engineers make mistakes. You could employ an infinite number of monkeys to write code and the design process to the standard would still almost leave you with the safe and functional code. Not quite true, because there are subtleties in that when many mistakes are made in coding it becomes really hard to spot them all. But all you have to do - in fact all you can do - is aim that the coding is reasonably competent and the guidance is followed.

How much college education helps here is an interesting point; the software processes that are learnt are probably going to be outdated by the time the student actually has to do safe coding, however they may have picked up the idea of following rigorous methods which - frankly - they are unlikely to do sitting in their bedroom trying to develop the next multi-million dollar app. And the biggest frustration amongst lecturers is that students do not appreciate this until years later - at the time they criticise their lecturers for being 'slow', 'picky', 'focussing on trivia' (come on, how many of us didn't see our lecturers like that at the time?) Neither approach - rigour or creative fumbling - is right or wrong; I personally feel we need creative software engineers and rigorous software engineers, and if managed successfully both can learn from and appreciate each other.

I must add that I'm not a great fan of design by processes and standards generally, but in this particular case it does seem to work extremely well. of course at the higher SIL levels there should normally be diverse software teams following diverse rules, so even if their incompetence causes both teams to make the same mistake at least the consequences will be different

-------------------------
Andy Millar CEng MIET CMgr MCMI

http://www.linkedin.com/in/millarandy

"The aim of argument, or of discussion, should not be victory, but progress." Joseph Joubert
 24 April 2013 07:54 AM
User is offline View Users Profile Print this message



AndyTaylor

Posts: 162
Joined: 24 November 2002

When I was at college (electrical and electronic engineering) producing 'good' code was only a small part of the work involved in computing assignments. In fact in the 6502 assembler work I had already produced code at school which answered some of the problems posed, but I realised that simply handing in a code listing would only get me about 10% of the marks available. We knew and understood that the code we were producing was created on slightly outdated systems, and the problems set were nothing new, but the main purpose was to learn and understand the processes of coding and testing.

Safety-wise I have worked on many safety critical systems, and in no case could I see a situation where a failure could be attributed to an individual. Work was done as part of a team, we would have peer reviews of work from within the same department, safety studies from another department, testing would be yet another department. Our customer employed engineers to assess designs, QA to monitor processes etc, their customer would be involved (QA) at every stage, and the end user would be involved in any trials on the submarine or at Land Based Test Sites. In addition where one system interfaced with others, then there was a duplication of that whole process with the other subcontractors, and interface testing was very rigorous.

The only individual responsibilities (more than one) in the whole process is with those people who sign off the designs and systems, and not with the individual engineers who originate the work. For sure it will be possible to trace coding errors to the person who produced the code, but it is not possible to lay the blame at their feet without acknowledging many failures in the project life-cycle.

There is of course a full spectrum of coding / design quality. We would hope and expect that the poorer and more obvious errors are picked up early, for example in unit level testing, and more subtle problems might be seen later in system level testing. At the point of system level testing we will also find the more subtle problems appear that have nothing to do with good/bad code but which are in fact down to ambiguities/errors/omissions in requirements.

So the quality of someone's coding is only a small part of the picture, if they are rubbish at coding but fully understand the principles they may still pass the college module, and their coding errors will be picked up quite early in the life cycle when at work, but even if they are brilliant at coding and never make any errors at all, their brilliant coding of an erroneous requirement can still lead to failure.

-------------------------
Andy Taylor CEng MIET
 24 April 2013 10:53 AM
User is offline View Users Profile Print this message



amillar

Posts: 1918
Joined: 28 May 2002

Originally posted by: AndyTaylor
...but even if they are brilliant at coding and never make any errors at all, their brilliant coding of an erroneous requirement can still lead to failure.


Beautifully put!

I was also going to add last night (but my dinner was ready ) a short story going back to the point about training and competence:
We are about to re-install an ancient piece of test equipment which injects high currents at low voltages (4000A at 5Vish max) through equipment. It's not actually particularly dangerous, but it looks it, and you certainly have to be aware of the burns and subtler magnetic field issues. At a site meeting our HR administrator tried to insist that only trained technicians should use it. I said that actually only engineers would be using it, to which the administrator's reply was that this was unacceptable as engineers are renowned for not following training or reading the manual. I tried to point out that since the company that built the equipment had long gone out of business, and in any case the equipment had been modified by us, who was going to give the training or write the manuals? This caused a complete logical breakdown - fortunately the meeting moved on. What we are actually going to do is that two of us will inspect the equipment and define safe procedures before we use it: one of my staff who is - amongst other things - 17th ed trained (which I am not) will ensure that where it can comply to standards then it does, and where there are no applicable standards we'll work together to investigate the safe procedure from first principles, which where the Chartered level of knowing how to write rules where none exist comes in.

What is deeply scary is the high prevelance of this attitude that everything has already been invented / discovered and that there are rules to cover everything: you just need to be trained in them. Working in innovative safety-critical design is excellent for daily demonstrating that following the rules (or what you did last time) is never quite enough. And that's where the fun end of engineering begins!

-------------------------
Andy Millar CEng MIET CMgr MCMI

http://www.linkedin.com/in/millarandy

"The aim of argument, or of discussion, should not be victory, but progress." Joseph Joubert
 25 April 2013 08:04 PM
User is offline View Users Profile Print this message



jencam

Posts: 608
Joined: 06 May 2007

Originally posted by: westonpa
And so it would be better to have the work checked by a second competent software engineer


They say that two pairs of eyes are better than one but we are back to the question of how competent is defined. Who watches the watchmen?

You speak about your son a lot, do you let him drive a car knowing that he could crash and die or did you take him out in your own car knowing that it was possible you could crash and die? How did you assess your/his competency?


He passed a driving test leading to a nationally recognised qualification. Holding a full driving licence does not guarantee that he will not have an accident in the future but that he is deemed competent (on that day) at handling car on the road to a level set by the government to be allowed drive unaccompanied.

Maybe you are not aware of all the laws which exist with regards to health and safety, both statute and civil, but if a person is found to have been negligent and this led to a negative outcome then there is enough law already in place to take appropriate action. But the question then comes down to was that failure caused by someone's negligence and that would be decided by 'experts' in the relevant field and the relevant judge etc. Generally if the person was incompetent the 'experts' will easily arrive that decision however it is not always so simple. Let us say that the sofwtare engineer was asked to write a reasonably large program for some safety critical device/equipment and sometime later a bug was found and which had caused a fatality. Was it the software engineers fault or was it the lack of testing? Who is then responsible for the testing, the software engineer or other people in the company who maybe assign a budget to the project? Should it have been tested better on site? Was there maybe an issue sometime before which did not cause a fatality but went unreported due to some other reason? Etc., etc., etc. Was the software engineer actually the best person for that job or was he/she the low cost version who was prepaired to work the long hours? Was that bit of software code written at the end of a 14 hour shift or just after someone walked into the room and started talking about the next project and so disturbed the concentration of the engineer?


I'm not a lawyer but I am aware that legislation relating to software reliability in safety critical systems is less developed than, say, legislation concerning fire safety in public buildings. A disaster resulting from a software failure has the potential to result in a very lengthy and difficult legal case both because of technical factors and the nature of the legal system. Hard and fast legislation where compliance can be determined by visual inspection or simple analysis is one thing. Having to perform all manner of complex tests on code - that could take months or years to find a sneaky bug that causes software failure in highly exceptional instances - in an environment where the law is vague or grey is another. Has anybody got any legal case studies of disasters resulting from software failure?

It is also important to remember that technical standards relating to reliability are not the same thing as law of the land.

But holding the degree does prove that a person can learn and digest and use information to that level.


It basically proves that the person can memorise information and then regurgitate it in an exam. The quality of the information is a completely different matter. Is a test of memorisation of material of uncertain quality actually a substitute for a proper training course by people who are deemed to be experts in software reliability?

University degrees are more of a test of memorisation than a process of acquiring useful knowledge for the real world but they are not the only example of a large scale degree of memorisation. The now defunct Kwik Save once required all of its checkout staff to memorise the prices of over 1000 items because the company was too stingy to deploy bar code scanners or stick price tags on every product. There are also many people - including children as young as 12 - who have memorised the entire Qu'ran. Does memorising the entire Kwik Save price list or the Qu'ran confirm that a person is able to learn in the same way that a university degree does?

but you and I are the 'older' generation and we are more responsible for today's education system than is your son or my son and so maybe if the relevant courses are not as they should be then we should take some of the blame and try to improve the situation.


I'm not sure where you get this idea from because it is very disingenuous. Only government ministers, teaching unions, and university professors have any power and authority to make changes to the state education system. My own involvement with schools and the local authority over the years to a level that few other parents have ascended to has hammered home the message that I am totally incapable of exerting any influence or changes to the education system. There was a time when I considered becoming a school governor until I was informed that governors no longer have any say or decision over what the school teaches and how it is assessed after the NC was introduced which is controlled by central government.

When we employ a software engineer then we can check their qualifications and previous experience and then also check their work whilst they are working for the business and in addition we can put in place other systems to ensure secondary checks on that work and systems to ensure that out in the field errors are quickly picked up and addressed and new learnings are fed back to make improvements. Thereafter if a person is found to be incompetent then take them through the disciplinary procedures if it cannot be solved by more training, supervision, reassignment, etc. I think one of the big issues is that if one company sacks somebody because they were incompetent then they are unable to convey that message to the next employer. That is not an easy one to solve because of course some employers may not be correct in that assessment and the new job may be slightly different.


We're back to square one in that competency is a subjective matter in the absence of nationally recognised training courses and qualifications. The industry ends up policing itself.

Managers and supervisors who sign off work could have got to where they are because they have team leadership qualities or through favouritism rather than a natural talent for spotting bugs in the code or an expert knowledge in testing, so bugs could slip through undetected.

Originally posted by: amillar
How much college education helps here is an interesting point; the software processes that are learnt are probably going to be outdated by the time the student actually has to do safe coding, however they may have picked up the idea of following rigorous methods which - frankly - they are unlikely to do sitting in their bedroom trying to develop the next multi-million dollar app.


Over the decades a wealth of knowledge about good software engineering practices and rigorous test procedures for safety critical software has been generated and there are many books and journal articles published on the subject. A software developer or tester who has studied them will be in a better position to work with safety critical software than one who has studied just to pass exams or worked only on low risk software, like iPhone apps. The knowledge of software engineering practices is the difference between a quality software developer or tester and a 'hack' programmer.

I personally feel we need creative software engineers and rigorous software engineers, and if managed successfully both can learn from and appreciate each other.


The two are not mutually exclusive.
 26 April 2013 11:27 PM
User is offline View Users Profile Print this message



westonpa

Posts: 1771
Joined: 10 October 2007

Reads more like a rant against degrees, Kiwk Save and management. Shame really.

Regards.
 26 April 2013 11:59 PM
User is offline View Users Profile Print this message



jencam

Posts: 608
Joined: 06 May 2007

Originally posted by: westonpa
Reads more like a rant against degrees, Kiwk Save and management. Shame really.


You can say what you like but maybe I have noticed something that you haven't or have downplayed the importance of.

I could be wrong here and I hope I am, but I'm under the impression that the IET as an organisation often fails to intuitively look at things from first principles and contains many members who prefer to maintain the status quo.
Statistics

See Also:



FuseTalk Standard Edition v3.2 - © 1999-2014 FuseTalk Inc. All rights reserved.