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.
However, this dosn't stop everybody and their dog from calling themselves engineers! Not that I really care, I just find it one of the most abused words out there. How many people out there call themselves doctors who don't have a medical degree.
'Men never commit evil so fully and joyfully as when they do it for religious convictions.' B. Pascal
I see a *HUGE* problem with requiring licensure to practice software development, aside from the legal ramifications on open source work.
I do mostly low level coding, firmware, device drivers, things of that nature. I can interface with anything I can get a spec for.
I do not, however, know much at all about application development. I do not know much about writing an OS. I do not know much about game development. Yes, I can understand the concepts involved, but that differs from having the familiarity required to do those things with confidence in my abilities.
I agree that making software less of an "art" would help large corporations take fewer risks in hiring coders. While not a big fan of "That which benefits M$ benefits America", I can also see the side benefit of helping to separate the real developers from the web weenies.
Until we have only one platform, however, with only one API, only one programming language, and only one conceptual model (ie, OO, which I personally dislike), software development *MUST* remain an art.
You sound like you think that you've been through the ringer getting to your current state of knowledge. I tell you now, that YOU KNOW NOTHING! Your're a pup! Still wet behind the ears! Program for the next 5 years, and keep up with all the new standards and learn 1 new language a year (at least) then you will be a developer.
9 Month IT course, and 2 months on the job and he thinks he's a developer. Still WET I SAY!
You're right. No, being licensed won't improve software quality. But, it does improve accountability.
.and if something bugs out, then Microsoft will foot the bill. As consumers we get told "dont use this in a safety critical system, a real time system, a system where you need X uptime or reliability" and worse, we buy it still! Would you buy a car if the dealer said "we think your airbag will deploy, but just to be safe, try not to get into an accident"
Take the bridge building analogy. If an engineer designs a bridge that falls apart and people die, they are liable. His company may also be liable. If a city engineer put his stamp on the bridge design, then he is also liable, and perhaps the municipality he works for.
Why should software be any different? We get mad when MS Word dies on us and we lose an hours work. Can we sue Microsoft for lost revenue because we missed a deadline because of that, and therefore missed a contract? Probably not (well, I haven't read a EULA lately) but there's no reason why we shouldn't be able to. Actually that was a bad example. Lemme try again.
How about a software firm contracted to write a control system for a city's traffic grid. A bug or poor design causes a set of lights to go on the blink, two people run an intersection and both die in the resulting collision. Who pays the damages? Not sure, perhaps the city... but its not their fault. But they can't pass that onto the software firm... not currently.
But instead, if we had licensed software engineers, who in certain instances like the one above, who were now indefinately liable for their work, and who are required by the customer to "sign off" on it... well, it can only bode well for the quality of software.
The big thing here is that the customer has to demand accountability --> Im sure that big e-commerce data centres demand guaranteed uptime from Microsoft..
As an engineer myself, Im constantly reminded of my responsibility to society. Alright, I don't write code for the space shuttle, or code that flys your 767 to Bermuda. In fact, I don't write code that even sees a customer. But I do write code that tests product (in this case radio systems for police and ems). If I screw up, don't properly test my code, then the product code is not properly tested, and perhaps at a critical moment a system will go down and a police officer facing a dangerous suspect will lose his life. That sucks.
Consumer software should be no different, but we don't demand the accountability.
Background: I am a chemical engineer, and I currently work in water treatment. /.ed, so I'm not sure entirely what the IEEE is up to. However I would think that there is a definite need for accredited software engineers for software systems that would pose a hazard to life or limb by their failure. A control system for an oil refinery, or medical equipment, for example are no place for feature rich bloatware that needs to be re-booted once a day.
To me an essential part of engineering has always been a sense of responsibility to society as a whole. Technology is harnessing natural forces in a way that provides benefit to someone or some group. Engineers try to ensure that this technology is used is as safe a fashion as possible. Minimization of risk. Planes stay in the air, bridges don't fall down, the water is safe to drink.
The article is hopelessly
The other side of the responsibility coin is liability. Engineers must show due diligence and carry liability insurance. It would likely be easier to insure an accredited software engineer working on a mission critical system.
I'm anxious to see what might come out as accreditation criteria for software engineers. I hope it would require some knowledge of the larger technological context and social responsibility.
Laugh while you can, monkey boy!
At least I had the guts not to hide behind "Anonymous Coward".
This space left intentionally blank.
For electrical engineers, the elegance may be in minimzing the number of transistors in a design.
For chemical engineers, the elegance may come on the form of the safety or usefulness of the byproducts of a reaction.
All engineering fields value elegance in method and design. The notion that "art" separates programming from other engineering endeavors is bogus.
Your statements are well thought out and valid, unfortunately the group-think of /. is so peversely self-contradictory that it really makes you wonder where common sense went. You see, /.'s rail against certification every time an article comes up suggesting it, but then they spend the rest of their time bitching about Microsoft's crappy software and how horrible it is that they "get away with it".
First you need that Engineering degree, and they are really nasty about transferring credit or allowing courses to be challenged. Basically, figure at least 3 years as a full-time university student if you already have very relevant training.
But then you need 4 (IIRC) years as basically an apprentice, working full time under the direct supervision of an accredited engineer. Naturally, this is, "We can end your career before it even begins!" internship-type employment.
So we're talking about a bare minimum 7-year investment (more likely 8 or 9) before they'll even look at you. These restrictions have been tightening up, requiring larger and larger investments in time, over the last decades, and I expect it to continue in this manner.
It seems to me that all of our professional organizations are slowly becoming old-fashioned guilds, organized less for the benefit of the general public and more for the members. Organizations in which one doesn't become a full member who can work unsupervised until middle age, assuming one commits oneself in one's youth. They already have the protection of government, so entrenched that nobody ever seems to suggest weakening their monopolies.
Do we really need a Bar Association? Do you think lawyers are more ethical, more beneficial to society because there's a government-granted monopoly to its members on arguing the law on others' behalf? Do you think your area's medical association is doing the best possible job producing competent, efficient doctors with no competition or alternative of any kind?
How many professionals are just wielders of required rubber stamps? How many brilliant young potential innovators are slowly crushed into mediocre clock-watchers, who have been shown again and again that putting your time in, looking respectable, and covering your ass pays off better than doing your job well and advancing the state of the art?
I think that far too few people question the value, competence, and good faith of professional organizations. They're just accepted as natural features of a well-run society, assumed to be the best interface to highly specialized skills without an active evaluation.
I look at them, and see the gradual calcification, then downfall of our society. I see never moving beyond asphalt roads and cars that move at 60 MPH, never moving a viable population off the planet, never extending the average human lifespan beyond 100 years.
I hate to see people talking about moving this kind of influence into software. It's one thing to run competing private organizations that certify certain skills, it's quite another to start legally requiring certification from a particular one, giving it monopoly status. Let alone ceasing to question whether it should keep that status.
because there's more to software engineering than just patterns.
Anonymous posts are filtered.
Several years ago, many states attempted to enforce the laws on their books to require anyone acting as a professional engineer to be licensed as such by the state. As anyone who has ever achieved a Professional Engineering (PE) license can attest, there is no comparison between a PE and a MCSE. Comparing the exams would be like comparing middle school to college. The PE exams in most states are brutal. As far as I know, Texas is the last state to enforce the law as it applies to software. Many of the companies in "Silicon Valley" threatened to relocate of California enforced the law there. So, California (like many other states) changed the law to apply to structural and electrical engineering disciplines.
I'm studying software engineering right now in Quebec and when my group finishes, if I dont fail too many courses, I should be among the first software engineers in Quebec. I think Ontario and other other provine are 1 or 2 years ahead. That menas that by 2002 there should be Software Engineers(tm) in Canada.. Btw, at least in my province, you cannot state that you are an eng. if you are not official eng. so MCSE's have to have a different name and everything. They are definetely not engineers.
;)
But right now, the only privilige that software engineers will have here is to be able to sign with a eng. at the end of their name.. Our names
Good luck to my American coleagues!
Tester
Student in Software Engineering at Polytechnical School of Montreal
Yeah, I'll love it when Software Engineering is considered a "real Engineering discipline". Just like how much I want to to program to ISO 9000 compliance so I can be a "professional". Screw it, call me a duck and let me do my work.
Anyway, storing programming patterns are fine, but a repository of them is going to help me very little in my job. Hell, I haven't even gotten around to reading Design Patternsby Erich Gamma et al. Programming is art as much as it is engineering; it is akin to being both the architect and the engineer.