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.
21 April 2013 at
01:59 PM by