Re: [SystemSafety] professionalism (was: Re: Logic)

From: Steve Tockey < >
Date: Wed, 19 Feb 2014 15:38:40 +0000

I think the critical issue is whether or not those guilty of the behavior you state were or weren't members of any professional society. I meet thousands of "paid professional software developers" every year and only a very small percentage of them have ever even heard of IEEE-CS or BCS or anything like that.

For what it's worth, I run the CSDP and CSDA certification programs for IEEE-CS. Candidates need to sign a statement saying they have read, and will abide by, the IEEE-CS/ACM code of ethics. If we can prove that any certificate holder is/was not abiding, we (I) willówithout questionórevoke that certificate.

I don't know about IEEE-CS as a whole, in terms of if they have ever revoked membership due to some kind of professional or ethics code violation. I know the president of IEEE-CS personally, I can ask if you want. I suppose that if there was such an expulsion that the CS would not want to make a big media deal out of it, they'd probably want to keep it as quiet as possible.


From: Martyn Thomas <martyn_at_xxxxxx Date: Wednesday, February 19, 2014 1:55 AM Subject: [SystemSafety] professionalism (was: Re: Logic)


I have a high regard for IEEE-CS and I have serrved on policy committees of the BCS and IEE/IET in the UK. Let me prespond to just one of the points you make.

On 19/02/2014 01:09, Steve Tockey wrote:

5. The governing body must take disciplinary action including, if necessary, expulsion from membership should the rules and standards it lays down not be observed or should a member be guilty of bad professional work.

5. This is already in place in IEEE-CS

I have spent many years as a consultant and expert witness reviewing UK and overseas projects that have run into difficulty. I routinely found commercial (not safety-critical) software development projects that had the following deficiencies (among many others):

  1. The requirements statement was incomplete and highly ambiguous, leading to major disputes late in the project about whether a clarification was a chargeable change.
  2. The initial plans were incomplete, superficial and absurdly optimistic. The project was priced to win the contract, not on the basis of realistic costings, with the intention of recovering profit margins later.
  3. The project risk register, if it existed at all, was superficial and the risk mitigation activities were trivial (for example: RISK: "the requirements may not have been captured fully". MITIGATION "Change Management Board").
  4. The plans contained no allowance for any impact from the risks materialising.
  5. Milestone definitions were vague, so milestones (especially payment milestones!) were claimed as "passed" when work and risk had actually been moved to later in the project.
  6. Key project documents lacked version control.
  7. The main assurance activity was testing, at a late stage in the project, with no planned time or budget for correcting any errors found.
  8. Technical decisions were taken for unprofessional reasons (such as "we wanted to gain experience of using this architecture or programming language").
  9. The lack of specifications and documentation is excused by the claim that "we are using agile methods".

I could go on (and on, and on ...)

I can say with some authority that there is no appetite in the BCS or the IET for taking disciplinary action over such unprofessional behaviour by members (even though both institutions have codes of practice similar to those of IEEE-CS). I'm not aware of any occasion in which a UK member of IEEEE-CS has been expelled for unprofessional behaviour either (though it may have happened without publicity).

Are things so much better in the USA? If so, how was it achieved and how does the IEEE enforce its excellent ethical standards?


The System Safety Mailing List
systemsafety_at_xxxxxx Received on Wed Feb 19 2014 - 16:38:55 CET

This archive was generated by hypermail 2.3.0 : Sun Feb 17 2019 - 21:17:06 CET