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.

Comments

Licenses Required?

[aridhol]

The article is slashdotted, so this is based on the writeup.

Requiring a license to be a programmer is a bad thing. If you think it will improve software quality, you're mistaken. Think I'm crazy? How many software contributers have an engineering certification? Sorry, no cert, no programming. No open-source software.

OK, so let's change the rules a bit. "You must be certified in order to write commercial software". You think that will help anything? Who determines what classifies as commercial software? Is my Mandrake CD commercial software? If so, does that mean all the software on it, including the free software, is now commercial? Not good.

However, what if there's a non-commercial certification process. Run, not by RedHat or Microsoft, but by a vendor-independent group of engineers. You prove to them that you are a capable engineer/programmer/whatever. They give you a certificate that actually means something. Perhaps require the certification to be re-written every N years.

Now, companies can have a certification that says this person is a software engineer. Not a Microsoft-certified software engineer. Not a RedHat-certified software engineer. An engineer-certified software engineer. No commercial influence, transferrable skills, and a large skill set.

Professionalizing Software is Premature

[Crispin Cowan]

Professionalizing software development entails:

1. Codifying a set of "best practicies" that, when applied, assure a solid product.
2. Codifying educational programs that teach these best practices.
3. Certifying people who graduate from the educational process as "Software Engineers".

The big problem with this idea is step 1: Sure, we have best practices, but they do not assure a solid product. By far, the highest assurance practice to date for developing working software is to make sure the developers have a lot of talent and dedication. There are software engineering best practices, but when goobers apply them, they are fully capable of producing bloated non-working crap. This is characteristic of an art, not an engineering discipline.

It is very nice that people are sufficiently concerned about software quality and its impact on the real world (e.g. comp.risks). But this in no way means that we actually have best practices that will assure that mediocre developers can produce working product. Wishing for it (or mandating it) will not make it so.

Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for Purchase

Re:Developer with no CS Degree

[malkavian]

Well, I don't think you'd be useless, and perhaps that's the wrong way to look at it.
What you need to consider is:
Do you really consider you know as much about the structure of programs (in general), putting software together, and have as broad an overview and experience as someone who's spent 20 years intensively studying and applying software, and trying to refine it to it's optimum, and is at least as talented as you?

The idea of accreditation is that you take people with the talent, and subject them to several years of rounded exposure to the whole of the discipline, so they don't fall foul of errors caused by lack of understanding of associated areas. You then test these people to ensure that they don't make the stupid mistakes that can and frequently are made by people applying good methodology in a stupid way (it happens).
What is being rewarded is people who went into a field because they liked it, and followed it, and gained experience. Don't call it luck, 'cos I don't buy that.
You chose your path, they chose theirs, and perhaps, just perhaps, they're being rewarded for the initiative, independant learning, flexibility and gumption they showed in choosing their career because it's what they wanted to study in the first place!
If you consider that in 11 months, you're on par with some of the old timers that HAVE been in the game for 20 or 30 years (I've worked with some in my time), then, I think you're exactly the kind of person that shouldn't be an engineer.
These things take time. If you want full accreditation, you should be prepared to do the graft and sweat that the rest of the world put in, even if it means going back to study full time again for several years, to re train from another discipline.
It seems that perhaps the move is partly to prevent the influx of people who've suddenly realised that there's a fast buck to be made in the computing world, and take a fast track that trains intensively in one area, to get them able to perform programming tasks, and these people pushing that envelope into areas they were never trained for.
I'm sure you're very good at what you do, and I'm in no way trying to take away from you what you have achieved, and yes, I agree, it's quite an achievement. I just ask you not to belittle those people who had the insight to choose their career early and stick to it.
As to the cries I hear here in the UK so often of "Oh, but that's so ELITIST!".. Well, yes. But I'd rather be travelling in a plane programmed by a set of guys who have proven themselves to be the elite by many years of peer review and monitoring, than a bunch of guys who thought maybe this would be the best way to assemble an avionics system, although they couldn't quite put on paper why that was so...
Knowing the Slashdot of today, it's quite likely this will be modded down, but, I've worked with gurus claiming to be fools, and fools claiming to be gurus, and I say what I see.

Malk

Mutual Exclusion Syndrome isn't good for anyone!!!

[Zero__Kelvin]

"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."

On the surface viewing Software Engineering as all science and no art makes for boring documents and processes. When people are bored, they naturally don't do nearly as good a job. Indeed, the best Software Engineers have the science part down cold, but also have a natural instinct that is the direct manifestation of their artistic inclination. Art and Science are the Yin and Yang of Software Engineering, and to remove or diminish the role of either is to diminish the effectiveness of the software developer(s), regardless of which one you mistakenly choose to emphasize.

If one wants to improve the overall quality of their software they must develop both their left and right brain. To shun one in favour of the other is folly. It is no different than strengthening one leg and cutting of the other in an attempt to be more mobile. Hopping around on that one remaining leg will certainly make it big and strong, but mobility will suffer almost detrimentally. I guess that makes it a major unbalanced hop toward the different, and less effective, not a major step toward anything.

Perhaps these people have never heard of the Software Engineering Institute and the Capability Maturity Model? Then again, what do I know? I'm too artistic to be any good at Software Engineering ;^)