I realize that this question is quite similar to this one, but news of a PE exam being developed specifically for software engineering by the NCEES and IEEE has piqued my interest.
Should software engineering professionals take the (upcoming) PE exam for software engineering in addition to their degree (or relevant work experience)?
Note: I realize the exam being developed is still sometime away, but I'm curious about the thoughts of the professionals active on Stack Overflow.
I have a BSEE. My university required that all graduating students take the EIT (now FE) exam. You didn't have to pass, but you had to take it.
I took it, passed it, and have done absolutely nothing with it since :)
I haven't taken the PE exam because I really haven't seen the need. I guess it depends on your goals. Right now I'm working for a manufacturing company and I think we have 2 PEs in the entire place, and only one is doing active design.
Truth is, even when I was working as a EE, there weren't that many PEs around.
I say if you want to as a since of pride, or your employer will give you a slight boost, go for it. Not sure it increases marketability for us software folks, but that's just me.
I remember when I first told my grandfather, who had a world war II-era civil engineering degree, that I was a software engineer. He was incredibly angry that I didn't have to pass a test to call myself an engineer; he apparently didn't pass the test the first time, and it locked him out of several professional organizations and therefore out of several jobs as a result.
I have no idea if that's still the same story for other engineering disciplines, but I do think that there could be a balance struck. I've worked alongside people who have had no business calling themselves software engineers, and I've worked with people too humble to admit that they had more than enough skill for the job they were doing. A reasonable and fair test could be a good way to distinguish between these types, in an ideal world. In a non-ideal world, you end up with things like the poll tax and other limitations based on criteria having nothing to do with competence.
So, I'm on the fence. If the test is anything like the CS GRE, then I know I would fail anyway, and I'd definitely not want that :)
I am of the opinion that there should be a software engineering exam covering everything from code construction to the engineering process. One of the significant flaws in software engineering as a course/textbook material is that it has a near-total orientation on the processes.
One of the books I found from the links you gave has this as a table of contents:
Chapter 1: Introduction to the Guide
Chapter 2: Software Requirements
Chapter 3: Software Design
Chapter 4: Software Construction
Chapter 5: Software Testing
Chapter 6: Software Maintenance
Chapter 7: Software Configuration Management
Chapter 8: Software Engineering Management
Chapter 9: Software Engineering Process
Chapter 10: Software Engineering Tools and Methods
Chapter 11: Software Quality
Chapter 12: Related Disciplines of Software Engineering
With due respect to the IEEE, that list is completely process-oriented in a fashion that provides very little practical understanding of how to build software from code. I have read books with similar tables of contents, and they were nearly useless.
Books such as code complete, mythical man-month and psychology of computer programming gave far more insight to the software creation process to me than the abstracted topics found above.
Perhaps if I was a lead software engineer at a mid-large size company, that above list would have more meaning. As it stands now with me in a junior position, I have a hard time getting anything but abstract concepts from it and the books that approach the subject at that high of a level.
The main reason for the PE exams in certain fields is that for public safety buildings, electrical design, etc are certified by someone who has passed the appropriate testing. This is so that gov't bridges don't collapse, buildings are designed to some reasonable code, and electrical design doesn't present obvious hazards.
Many types of engineers don't need to get a PE license - often they work in firms where a few people have the PE and sign off on everything, and other times they work in fields where a PE is not required by the customer - such as mechanical design for consumer products. The gov't requires all public infrastructure work signed off by someone with a PE, though.
There is no big need for that in software design, except, perhaps in aircraft and air traffic control design, nuclear power stations, and other software controlled fields that affect the public at large.
However, as the internet gains importance in the economy, and more and more of our infrastructure is controlled by computers there may be a need for this professional licensing.
But even once it's available, it won't be required for the majority of work.
By definition, civil engineers almost always work on public infrastructure, so they will almost always have PEs in their offices.
This bothers me (emphasis mine, from the linked press release):
IEEE-USA and the IEEE Computer Society will be working together to develop an examination requested by state licensure boards for prospective use in licensing software engineering professionals.
I don't see how it would be practical to license software engineers. I can't imagine any standards body that's capable of moving fast enough to keep up with current software engineering practices. Any test would be largely irrelevant before it could be given.
It would be possible to test for basic knowledge, sure. But if it's just a license for basic knowledge, then it has no value, certainly not for liability concerns. And I assume liability is the reason that a state would want to create a licensing board.
Imagine that, being a software engineer means you have to carry a license and insurance against bugs that you write!
Even the sharpest software engineers out there write tons of bugs. It's part of the job. A license isn't going to stop that from happening, nor protect anyone if it does.
(Besides, all software engineers know that writing bugs is their fault, but releasing bugs is QA's fault ... let's get some QA insurance in here! :)
Yegge's Tip #6 for a (Slightly) Less Awful Resume: Don't be a Certified Loser.
While I suppose the definition doesn't require it, I think part of the idea of "engineering" is that the field has some level of maturity behind it.
If a civil engineer designs a bridge, other civil engineers have enough of a grasp on the subject that they can tell you if it's going to fall down or not. If a mechanical engineer builds you a gearset, he can tell you how fast it can spin. They can tell you things like what the failure mode will be when it does break, and how much it'll cost and how many people will be required to build it.
"Software engineers" can't do most of these things, at least not to within any accuracy. Moreover, some things which were hardly thought out at all have managed to become critical infrastructure (Vint Cerf will tell you that IPv4 used 32 bit addresses because it was just an experiment, and if it worked they'd go back and do it for real). Some things which have been thought out incredibly well have simply not worked, with failure modes up to, and including, exploding.
Software simply isn't mature enough to be an engineering discipline yet. We haven't figured out the fundamentals yet. It's like trying to certify electrical engineers before Maxwell, or mechanical engineers before Newton: I'm sure you mean well but you're toying with ideas you don't understand. We're in the stone age of software here.
Imagine if a tiny band of rookies built a suspension bridge for automobiles out of toothpicks and gumdrops, and it worked great for the first 10,000 cars, and then they said "OK, now you'll have to drive slowly for a few weeks while we replace the toothpicks and gumdrops with steel girders". Then a second team tried to build a bridge but they started with steel from day 1, and that bridge went over budget by 10x and melted during the first rain. Would you be ready to call it "mechanical engineering"? I'd call it dumb luck. There are certainly many programmers who can do repeatably excellent work, but we don't have any reliable means of identifying them a priori, which is what an engineering certification would try to be.
You know, I never understood the reluctance in this field to certifications or other qualifications. Yes, yes, a large number of the people likely cheated to pass the exams, I get that. I would imagine in time there will be a number of braindump sites for this new PE exam. My old certifications never got me a job, but the process of studying helped me immensely. I just see certification as a more formal study process. I don't think having a certification does or should make getting a job easier. But learning will always make you a better candidate.
How many posts here or on blogs talk about getting the morts or 80%-ers to learn more or care more about this profession. This PE exam might just be that motivation. Throw in a 2-5 year re-certification requirement and you might just accomplish 2 things. 1) Flush out the people who are just in it for the money but can't be bothered to actually try. 2) Those that do stick it out will at least be forced to take an exam every few years and even if they cheat will at least have to memorize... something.
Should this new qualification be required to work in this field? Absolutely not. But it should be encouraged. I work with finance people all day long and their email signatures look like the alphabet exploded. I just don't see the harm. But that's me, I like learning new stuff. That's why I'm in this field. If this PE thing actually happens, I'll be one of the first to try it out.