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.
I've found thousands of really detailed, useful pages about software engineering, design and manufacture at the Portland Pattern Repository. Why are they trying to make yet another big repository with a structure that doesn't neccesarily scale as well as a wiki?
To see the PPR, surf to http://www.c2.com/cgi/wiki
"Look at me, I invented the stove!" -- Ben Franklin
Microsoft says I'm a systems engineer. I studied long and hard for the exams. And then had to relearn almost everything for the real world. You wouldn't believe my surprise when I found out that in the enterprise people don't use NT boxes as routers and use third party software instead of NT backup and a tape drive on each server. But getting back to the point. How come I'm not considered a "real" engineer? I got my license from Microsoft. Like developers are real engineers anyway. All they do is click, drag and drop code in until they say it's ready. Then the patches come out.
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.
I can't say that I don't give a fuck. I've just run out of fuck to give.
So because I have no university degree I'm suddenly considered useless? I studyed long and hard to change careers from banking. I took a 9-month intensive IT course which was at times very hectic. The J2CP exam was no joke, neither was the 60% of my knowledge that I learned without formal training on the job in my first 2 months, or the first month of my new job, in which I had to learn yet ANOTHER new set of skills and development tools with almost no training whatsoever.
Are we suddenly going to stop rewarding initiative, independent learning, flexibility and gumption, and only give credit to people who were lucky enough to figure out their career paths in their late teens, unlike me? Proposterous!
This space left intentionally blank.
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!
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.
- Codifying a set of "best practicies" that, when applied, assure a solid
product.
- Codifying educational programs that teach these best practices.
- 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
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.
"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
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
The Association for Computing Machinery withdrew its support for this SWEBOK effort, after deciding that their approach to licensing practioners was inappropriate. So this probably isn't going anywhere.
In comparison with other engineering disciplines, the real problem is that we don't have a good handle on how to build software with huge safety margins so that it doesn't need to be engineered.
This seems confusing, until you look at, say, structural engineering. If you want to build something, there are standard handbooks that will tell you how to build something that's much stronger than it really needs to be, but won't fall down. That's how most houses are designed. Only when you get into more complex construction (steelwork, arches, laminated wood beams, etc.) do you need a licensed professional engineer to sign off (literally) on the blueprints.
We don't explicitly make that distinction for software. With fifty years of computing behind us, it may be time to do that.
A good place to start would be control software for anything with more than some minimal amount of energy. (For example, programming a VCR control CPU wouldn't require certification, but a garage door opener control would.) We could then go on to, say, software that handles the money of others, and perhaps to networking software that can affect more than 100 users at a time.
A formal distinction of which software matters and which doesn't is the first step. The industry needs to take that step.
What worries me most is what you see on the front page of the site, namely the logos of a bunch of companies like Rational, Construx and SAP, who have vested interests in software engineering processes. If the committee goes away for a couple of years, comes back with a carbon copy of the Rational Unified Process and tells everyone they need to buy Rational Rose to get a certification, I'm going to be more than a little annoyed.
The basic problem is that there is simply no consensus in the industry as to what constitutes "good engineering" in software, beyond a certain very basic level. We're a very, very young discipline, and unlike structural or electronic engineering the mathematics does not exist to prove what we are doing is right.
In the absence of any real proveability in our craft, all you can do is make broad pronounciations, and then quibble about their interpretations. You can say "testing is good", but you'd never get a room full of programmers to agree whether test-first programming is better than testing completed code, and nobody's yet been able to determine which is more efficient under which circumstances. Similarly, you can say "well-designed code is good", but who's going to moderate the dispute between the CMM waterfall three month design phase group, the moderate Agile "design the module just before you code it" group, and the eXtreme "design is something you achieve as a by-product of merciless refactoring" party.
I have little faith in the mission of this group, as I can't ever see it coming up with a satisfactory document. Either the qualification for being a software engineer will be so broad as to be useless, or (more likely) it will mean that the industry will continue on as it always has, we'll just go back to being called programmers, and spend our time scoffing at certified "software engineers" as followers of an arcane, broken methodology.
Charles Miller
The more I learn about the Internet, the more amazed I am that it works at all.