Slashdot Mirror
Software Engineering Body of Knowledge
An Anonymous Coward writes: "The IEEE has a project going to establish a Software Engineering Body of Knowledge. I'd recommend that all Slashdotters read this and send comments to this since this project could lead to the officially designating Software Engineers as a real Engineering discipline. That could then mean that licenses could be required to practice software development and that this could to regulation and other legal ramifications." On the surface this looks like a fairly boring document/process, but this is a major step forward - turning software engineering from an art into a science.
At the university I attend there is already a Software Engineering curriculum, and if you take a look at places like the Carnegie Mellon Software Engineering Institute, you'll see that this concept has been around for a little while now.
This topic will have huge ramifications. Too many people call themselves engineers these days. It wasn't a problem in the past because the general public could differentiate between a "custodial engineer" and a professional engineer. Now, professional engineering is becoming blurred by more and more technical types calling themselves engineers, without even close to the training and standards a professional engineer is held to. I'm not familiar with American laws, but in Canada, you are not allowed to call yourself an engineer without a professional license. The Canadian professional engineering bodies have successfully stopped Microsoft, Cisco and others from calling their technicians "engineers". "Software engineering" is the most dangerouse of all, and in my opinion, the most needing of the professional designation, if only to apply appropriate training standards, ethics and liability. Think about it: don't you want to know that the guy who designed the fly-by-wire software for your 767 or A300 knew what he was doing?
It doesn't mean your are considered useless.
Electricians and electrical technicians aren't useless. They can get good jobs, they just can't legally design commercial electrical products (unless they work under a supervising engineer, of course).Electrical Engineers go through Ethics courses and Occupational Safety courses, and they have to take responsibility for the things they make.
If a professional Engineer designs something, it _MUST_ work as specified. If it doesn't, the consumer can sue the engineer that made it. With software (which is not made by engineers) doesn't work, you can't do much about it. That's the difference between engineers and non-engineers.
We have had some discussion on the C++ newsgroups recently, regarding the possibility of getting a decent C++ certification scheme started in the industry. Bear in mind that we're talking about a major language here, and one that has an incredibly high number of "users" who don't really know the first thing about it -- or worse, get that first thing wrong -- but think they're experts. There is no single commercial body that "owns" C++, so no political spin needs to be put on things. Basically, this is a prime candidate for certification.
Except that we concluded viable certification was not going to happen. Without a major industrial sponsor, and without a large body of experts who are actually qualified to administer the necessary tests, you'd never get it off the floor.
And what would "certified in the use of C++" mean, anyway? There are many different areas of C++ programming, and while some projects use most/all of them, other projects would never use, for example, much of the STL. To have any practical use, any certification would have to be more precise than just "good at C++".
Remember, this is just one language, and still the expert population felt it would be impossible to provide an effective recognition in today's environment. What hope can anyone have of effectively regulating software engineering as a whole in this today's development world, then? There are more contradictions in this industry than anywhere else I've ever seen, with some companies successfully using development methods for years where other companies have failed completely using the same methods. Who's to say, with any justification or authority, which methods a "chartered software engineer" should use?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I guess computer geeks don't have a sense of humor. I remember hearing somewhere that C coders don't think VB programmers are real programers or something like that. Don't remember the specifics. Thought I would play on that.
I do have a real MCSE. And I also realize that any certification program run by a company's marketing department isn't a real certification.
I was speaking to one of the members of the CEAB who visted LU on Monday. He recieved his P. Eng designation first in Electrical Engineering then later in Software. He said that the purpose of the Software Engineer should be for critical systems, namely those that if the fail, would put people in danger. The same as Electrical, Chemical, Mechanical or Civil or other Engineering professions.
This doesn't mean that only software engineers can work on such projects. It means that before the software is used it must be approved or 'stamped' by a Software Engineer with a P. Eng designation.
This is not currently required by law in Canada (AFAIK).
Again, this doesn't mean that all programs have to be written by software engineers, or approved by engineers. It is just proposed for software that is life-endangering.
For more information:
P.S. Education alone does not an engineer make! It is the combination of education and engineering.
P.P.S It is also possible to become an Professional Engineer without attending an accredited program. Several requierments must be met but it is possible.
All the IEEE seem to be doing is codifying current 'best practices' in software engineering in a similar manner to the Project Management Institutes (ANSI std) "Guide to the Project Management Body of Knowledge"
SE *is* project management as far as I've experienced it, or a subset. No-one with any sense would ever suggest that stds will prevent cockups in projects - but being totally ignorant of what many considers best practices will make you more likely to stuff things up.
I really can't see why developers get so upset about groups trying to put up hand-rails and guidelines for managing large projects.
If you're sitting coding up a wee access database for a mate or writing a little bash script to check your logs then you don't need them - but projects of a larger scale, involving many organisations and multiple teams DO benefit from guidelines.
Dave
Engineering -- the application of science for the benefit of man.