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

What about the PPR?

[LazyDawg]

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

Both kinds: Science and Art!

[TimTipple]

Hey, I'm all for recognising the science of software engineering. But don't let the pendulum swing too far the other way such that we end up forgetting the art of software engineering.

Art and Science

[deggy]

I still beleive that Software engineering is as much art as science. It's just less free-form. The biggest thing that most people miss is method and Structure (can you say SSADM? Aarrgh!). This is what leads to the failure of most software projects - the winning bidders (the lowest bidders) are often just a bunch of untrained amatures (Mostly "Microsoft Certified Professionals") who, while they can talk a good project don't know how to successfully complete a large task (only 20% coding time and all that) as they're only used to banging together a quick web-site/access back end. The art comes into making it efficient (Elegant code, a lost art to most MS programmers), The Science goes into realising that art in a functioning form.

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.

Developer with no CS Degree

[javacowboy]

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!

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

Re:Huh? I don't get the fears....

[Flakeloaf]

If software engineers become a trade, they'll eventually get their own union. This union would control the engineers' work by setting standards for education, and defining how certain jobs will be done.

I'll give a cookie to the first person who names a company that would be quite happy to control the board overseeing this as-yet imaginary union.

License to practice engineering?

[brunes69]

Needing a license to practice only applys to CERTAIN types of engineers doing CERTAIN projects. I can tell you right now that if you go to work for Intel, but don't have an EE, you're not going to be arrested or anything. Sure, Intel may be taking a chance, but that's their problem. Now, Civil Engineers designing bridges is a different issue.

I expect it would be the same for software engineering. Good (and neerly necessary) to have the certification, but it won't impede Free Software in any way.

Only if companies adopt this policy...

[Tazzy531]

Disclaimer: I haven't been able to read the article yet; it's taking a while to load up. (Plus, I bet only half of the people that post don't even bother reading it before posting anyways) Computer Science and computers have always been well ahead of the people that create and develop laws. IF this ever became a law, very few people would actually follow it. I mean, how many top-notched computer programmers actually have official title education? I mean, probably a quarter of the very best programmers out there started doing it BEFORE computer science even existed. Secondly, the only possible use that this would be would be if the government or a top-tier company needed a developer to develop a fail-safe application. Let's say NASA needed an application, this might be a benchmark for them to identify talent. Lastly, to some extent, I agree that software engineering should be come a little more structured. There is a major difference in the code style and programming style of programmers that have proper education and those that are self learned. With education, coding becomes a more structured practice. This is a valuable asset in a corporate or group environment. If a certain person write code that only he or she understands, it costs the company even more because of the greater amount of time that it takes for other people to learn his code and style. However, on the other hand, some self-learned individuals, not learning structured development styles, are able to take shortcuts or find optimizations to produce better codes. (As always, this is a generalization. There are obviously exceptions to these two rules.) So to sum it up, this IEEE proposal would benefit schools and corporations because it creates structure in programming style. However, something like this could never become law in the same way that you need a medical license to practice law.

Certify Software, not Software Engineers

[blair1q]

A certified engineer can still make a mistake.

Certified software is tested and putatively immutable, and you can always throw more testing at it if you think it needs it.

DO-178B procedures require that all software designs and implementations be reviewed and tested, the tests reviewed, and the reviews reviewed, by different engineers--or companies--wherever practicable. And it comes with different levels of certification, to allow cost reduction where lower levels of risk are involved.

--Blair

(Note to web surfers, if you want to go to yahoo.com, say, to find standards links, do not mis-type the domain as "yaho.com". Trust me on this. I also advise everyone to use Panicware's free Pop-up Stopper. This node is getting wrapped right now.)

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:Professionalizing Software is Premature

[richieb]

In traditional engineering disciplines, the laws of physics apply and do not change. On these laws, best practices have been built. No matter where you apply these practices, you can be sure the laws supporting them are just as they were before and will be tomorrow. This covers most of the work we consider "engineering."

Even in traditional engineering disciplines knowing the laws of physics may not help much. For example, consider civil engineers who try to control floods. We understand the basic physical process (i.e. gravity pulls water down), but the system of rivers etc, interacting with the weather is chaotic, and there is no scientific theory that tell us where to build dams to stop floods.

The problem is that engineers are asked to build things, whether the science to help them exists or not.

...richie

Creating Software is not Engineering

[parabyte]

In early days the Computer Science was considered as a part of Mathematics, which is plain wrong.

Creating Software in fact is a discipline requiring more artistic than mathematic skills; the best analogy in the "old" world is the Architect who designs houses; he also needs to be familiar with math and needs to know a lot about physical properties of different materials, but the real issue is to create a building where people like to live in,which requires to know more about people and what makes them feel comfortable, more about the history of art than the history of stone and steel.

Creating Software is about making a computer useful to people. Software is not for Computers; they feel equally comfortable with any piece of code; software is about modeling real world entities, and about creating interfaces to the human mind.

Even if you write a protocol stack or a kernel, something no normal user is exposed to, you are creating an interface that makes it possible for another programmer's mind to deal with it.

So it is not the silicon side of software, but the human mind side that makes the difference.

And now throwing in the multi-media aspects of today's most software it becomes obvious that in fifty years creating software will be considered as much an engineering discipline like making a movie today is considered as an engineering discipline because it is an opto-chemical process.

Btw: ever seen somthing funny, beautyful, lovely or cool come out IEEE ?

p.

Passing a test doesnt make you a good programmer

[HanzoSan]

This idea is just plain stupid. Its an attempt to make programming as esoteric as other scientific fields.

Problem is, we need more programmers not less, why make it hard as hell now to become one by requiring people go to special schools like a doctor has to go to medical school, and requiring they pass all these overly difficult tests ?

Passing a test does not make you a good engineer!!

[HanzoSan]

You just dont get it. Programming is not like building a house.

When you build a house, you cannot freely learn from millions of other houses built by taking it apart peice by peice and putting it back together.

Programming allows ANYONE to learn on their own and become a good software engineer.

Passing a test wont prove that you are good, It just proves you are good at passing tests.

The proof should be in your source code.

Perhaps as a test, requiring people write several programs and submit them to a review group, (similar to the driving test) so people can SEE they have skill, would actually be a better idea.

But to give a standard TEST, it doesnt come down to skill, it comes down to how much of the text book you memorized.

Its stupid.

The source code should prove someones worth, not a test.

Re:What about my MCSE?

[cornflux]

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.

I am a software engineer, and I don't work that way. In fact, I don't know any software engineers that work that way.

My guess is that your opinion is based on a lack of knowledge.

And, for what it's worth... I, and the other software engineers I work with, don't drag-and-drop code. Shit like that never works and you definitely don't learn anything that way. Furthermore, it's not my decision to decide when something's ready... i.e., it's ready when the software meets the functional and design specifications. To that end, I do my best to get things done the right way the first time. In fact, patches and fixes are highly frowned upon (because it takes resources away from new projects -- we move fast).

Whats the problem?

[Ars-Fartsica]

No one is claiming a certification exam would be perfect. Is the SAT perfect? The GRE? The GMAT? At some point you are going to have to comprimise and assume that no one will get everything right or everything wrong, regardless of their state of knowledge.

What is so difficult about going through Stroustrup's book and picking three or four topics per chapter and formulating questions from them? Some could be true/false, some multiple choice, and some requiring you to "write" code snippets. It seems pretty straightforward.

The problem is when most "expert" groups discuss this topic, they typically look for a test they could get perfect in, based on the fault assumption that their perfect mastery of C++ must result in a perfect score.

Re:Creating Software is not Engineering

[tius]

You are correct to a degree, but only for some types of S/W systems. For example, my word processor is artfully designed for me to intuitively make the most out of it's capabilities. Great, but it crashes due to sloppy, 'artful' practices. Ok, it's a word processor, I lose a bit of work...annoying, but not critical.

Now for the systems that I hope were not designed in a purely 'artful' manner: Aircraft control systems, my microwave oven, the telecom switches that connect me to emergency services, chemical/nuclear process control systems, automotive control systems, traffic light control systems, fire control system on a smart bomb, nuclear attack early warning systems, pacemaker control system, computerized medical equipment (life support, anaylsis equipment...etc.), electronic infrastucture for commerce...etc..

These are all S/W application areas that demand an engineered solution. That means that the system performs the required functionality correctly, meets the required level of reliability, and does not perform unintended actions in either normal or extrordinary circumstances.

Artistic qualities do play a role in design & implementation, but it is not the only quality required to build & test such systems.

Could you imagine someone 'artistically' testing such a system? "Well, the system 'felt' right...I think we should ship it." "Oh, it failed! It killed 300 people! Tsk."

Last word; Programming != S/W engineering.

Re:Creating Software is not Engineering

[mogens]

(How this scores 3 is a mystery)

Computer SCIENCE is very much part of mathematics. Denying it just proves that you slept through class, or avoided taking the hard classes because they had math in them.

Computer SCIENCE comes up with tools like VDM and Z (formal methods) that can be applied by ENGINEERS to verify that the software that was built.

Application Software construction is very much like movie-making already. You usually have a director (architect/designer), lighting and camera-crews (database and graphics experts) and so on. However, they all use tools like cameras, lights, and cranes (compilers, database engines, Open-GL drivers). These tools are usually certified by ENGINEERS who have used the processes that SCIENCE gave them.

Beautiful stuff does come out of the IEEE. 802.11b for example. Wi-Fi or Airport the marketing departments are calling it. Quite popular these days, apparently.

medieval guilds - revisited

[Anonymous Coward]

imho what they're trying to do by introducing
a certification is not a question of increasing
security and methodology, it's a matter of control.
once they can tell who's a certified software
engineer and who's not, they'll hold the entire
software industy by the balls.

The danger is that this drifts into a closed
corporatism like the guilds in medieval europe,
worse: it could be that "sponsors" (microsoft?)
direct which criteria you have to meet to be
certified

And last, since such certifications can't really
be hard, it could drift into a buyable title
just like you can read ads "buy your Ph.D."

so basically, we should closely watch who's
going to decide how it works.

Re:Your first sentence is incorrect

[Anonymous Coward]

Yes, you are a Microsoft Certified Systems Engineer, but that can't be broken down into (Microsoft Certified) Systems Engineer (as that infers a common standard that can be equally accredited by any body), but more to the point should be surrounded by quotes and an "TM" symbol.

Accountability is key ......

[Samuel Nitzberg]

I think that there are significant problems with relying on legal issues or tests alone for establishing or maintaining requirements for software developers, coders, managers, database people, etc...

There are a number of theories regarding why software fails. There are many studies, papers, etc... I have even been involved in a few of them. I don't know of any study or organization who feels that - at the very heart of the problem - is a shortage of licensing. At best, some sort of licensing -- might -- be of some benefit, but I don't believe that should be the first or foremost solution towards addressing software quality problems.

Many years ago, Scientific American magazine had an article on software; this article cited complexity as the reason software fails. I disagree. There are arguments about how complex software is - the difficulties associated with testing all computation branches and [execution] flows through a program (exponention, NP-C problems), testing software and module linkages, data typing and related matters, and many other issues. My experience and understanding is that most software problems relate to poorly thought out requirements, poorly documented changes, work done under time pressure, and a host of what I will call "fundamental" failings from software developers.

I think that advanced training in software - degrees with math components, and formal software engineering training can be genuinely helpful. A great problem is organizations that do not know or care about the consequences of flawed work going out the door.

Ultimately, with or without any form of licensing, I see one major step that would help software quality - ACCOUNTABILITY. There must be legal liability for software that doesn't work, or is purely dangerous. The onus must be on the producers of software to do the job properly.

I know software can be large, and can be complex - but it also often sloppy, poorly thought out, and problems are considered post-release headaches.

My presentation at H2K (Hackers on Planet Earth, 2000) addressed some of these issues. The presentation focused on Ethics in Military and Civilian Software Development. You can find this online from http://www.2600.com, and then following the link to the presentation. I have other papers that discuss this and related issues, also on my web site.

Sam Nitzberg
sam@iamsam.com
http://www.iamsam.com

No more licensing!

[omnirealm]

That could then mean that licenses could be required to practice software development and that this could to regulation and other legal ramifications.

No, no, no, no, NO, NO, NO!!! Keep the government AWAY from it all, for pity's sake! We don't want legislation to dictate who can and cannot write software. In my county, my wife and I are not allowed to cut each others' hair in the privacy of our own home. Because beauticians got together some time ago and petitioned the government to make it illegal to cut hair without a "license." To get a license, you have to go to a qualified beauty school and then spend so many hours cutting hair in professional, and authorized, salons.

Of course, they then artificially limit the number of beauty schools that they allow to train for such licenses. The same thing happened in the medical profession. This sort of thing is routinely done by factional groups to pressure the government to create a stranglehold on the market, reducing supply and thus letting them charge more for their services.

In the long run, it only winds up hurting us all by driving the price up while not increasing the quality of the services we receive. Do you really think that having an "official license" makes doctors better than they would be otherwise? Are "certified" Microsoft Engineers any more qualified to work with Microsoft products than the rest of us?

Bad and good beauticians and doctors can be singled out by this little phenomenon called reputation. We don't need a piece of "official" government legislation to be mandated on all who want to enter the market in some lame attempt to make things better than they would be without the artificial intervention (do a search for "Adam Smith and invisible hand").

Let anyone who wants to write software professionally, whether or not they have a degree, license, or whatever, and let the buyer beware. Let each entity build a reputation, and the market will pick the best man for the job.

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 ;^)

MS runs the world.

[Anonymous Coward]

I bet MS would support formal certification of software engineers before they could produce/distribute software. All of a sudden the idea of developing for an open source community would become cost prohibitive. The result, microsoft owns *all* the code. With as big as they are, you know who would write the engineering certification exam.

Q: What is Linux and Open Source Software?
A: A set of experimental and educational code not designed or intended for real-life use.

Hmmm, seems like any sort of certification will either take too long to implement, or will be yet another massive MS joke.

Too much process, not enough content

[Animats]

Those documents are about process, not engineering content. There's a strong bias towards a waterfall approach (first the requirements, then the design, then the code). They're really documents on how to manage.

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.

Too Many Vested Interests, Too Many Uncertainties

[carlfish]

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

Wrong, as usual.

[pixel_bc]

That could then mean that licenses could be required to practice software development

Sigh. No.

It would mean you couldn't go calling yourself a Software Engineer if you're NOT, but nobody is going to card you trying to buy a copy of VC++.