Posted
by
ScuttleMonkey
on Monday February 04, 2008 @01:54PM
from the code-as-an-art-form dept.

Jonathan Wise writes to share with us an interesting bit of prose describing life as a software engineer. "I am, in the States, known as a Software Engineer. In Canada we're not allowed to call ourselves engineers, although the discipline is no less rigorous than any other kind of engineering. But perhaps its for the best, because 'engineering' describes only a part of what I do. A software developer must be part writer and poet, part salesperson and public speaker, part artist and designer, and always equal parts logic and empathy."

Yea right. My latest specs went from "Spend some time with the latest version of the FooBar libraries we use and see whats changed" to "When will you have something we can look at and test?" in about 5 workdays.

A damned 'Engineer' in all the title's glory developed my car, and yet half the time a warning light comes on, I'm told to turn the car off, wait a minute, turn it back on and hope it doesn't show up again.
And the 'Engineer' that designed our local highway, forgot about this thing called 'grade' and why it's important to have water run off the road rather than pooling in the middle of it. Many millions of dollars later in court, it was verified that the Engineer f'ed up the plans and the construction crew

And the Engineer who stamped the plans before construction began is now personally liable for all the damage caused. That is the difference (in Ontario) between someone who is an Engineer, and someone who just calls themselves one (illegally). That person has probably been stripped of their certification, and can never work as an Engineer again. There are responsibilities associated with being a Professional Engineer, and penalties should those responsibilities not be met.

Dr. David Parnas actually succeeded in becoming a Professional Engineer (P.Eng) in Ontario as a "Software Engineer". He showed that there are rigorous ways of designing software so that the tenets of engineering safety can be upheld.

So yes you can be a software engineer in Canada. But not by getting a cereal box certification from Microsoft. Perhaps graduating with a degree in Software Engineering from a University like Waterloo or Toronto, which do have software engineering courses.

You CAN be a Software Engineer in Canada. You just have to get a Bachelor's Degree in Engineering (or similar) with Software as your discipline. Then register with your appropriate body (APEG-BC in British Columbia) and there you go. The University of Victoria offers a B.Eng. in Software Engineering. For the first four years after graduation, you can call yourself an Engineer In Training. After that, you can get your seal and stamp as a Professional Software Engineer.

In other words, yes, you can call yourself an Engineer. Just not after mailing in box-tops to MS.

Many millions of dollars later in court, it was verified that the Engineer f'ed up the plans and the construction crews were not at fault.

You just proved his point! There was a huge court case, and it was verified as to which party was at fault. The Engineer might have lost his license over it, too, if the damages were that high. So yes, that's the difference: the Engineer was held accountable.

But software is different, for some reason. For example, do you see that happen with Microsoft? Hell no! If Microsoft were held accountable for its software like Engineers are, the company would have been sued into oblivion and Bill Gates would be in jail for gross negligence. And so would the responsible parties of every other software company.

Two reasons. 1: the warranty disclaimer. Like it or not, "NO WARRANTY" is stamped on to the licenses of commercial software because software consumers don't want to pay the higher cost that would be demanded if a warranty were provided. SLAs do exist, but SLAs cover services. The market is willing to pay for SLA on services, and the whole system works, even if it's not quite as perfect as we might dream.

The other big reason is that a blue screen of death doesn't result in actual death. If you're building homes or highways, you have human life in your hands, and holding you accountable for negligence seems a bit more appropriate. If you're building door locks for the home and a burgular manages to pick it, holding you accountable for negligence is ridiculous because you never promised the lock couldn't be broken. If you're building the home's foundation and it cracks, you still aren't held liable unless you warranted that the foundation wouldn't break. And you wouldn't do that unless you could afford to fix it if it did.

Simple economics. The market has supplied what the consumer has demanded. But some people get these ridiculous ideas about licensing software developers or enacting liability laws when there is NO risk to human life. They try to draw comparisons to disciplines where there are, then gloss over the details. Under even the most brief analysis, the argument doesn't hold water.

(To expand on the ideas of your post)
A great deal of crap software is actually pushed out the door against the objections of the developers that created it. Ultimately it comes down to marketing and PR and not the developers in most cases as to when a particular piece of software is ready to ship. Also, as has been pointed out, people would be unwilling to underwrite the cost of a theoretically "perfect" piece of software that would never crash (barring hardware failure, or cosmic ray induced bit flipping)

Also, as has been pointed out, people would be unwilling to underwrite the cost of a theoretically "perfect" piece of software that would never crash (barring hardware failure, or cosmic ray induced bit flipping), because given the choice between a $50 piece of software that crashes once a week, or a $9000 piece of software that crashes never, almost everyone is going to pick the $50 one and live with the occasional crash.

I really hate it when these discussions become black and white. Software quality is not a binary value. It is a sliding scale with diminishing returns for effort put in, on which we are for the most part still at the "dirt cheap" end.

I doubt I would want to pay the price of near-perfection. I'll leave that for the nuclear reactors, medical facilities and space shuttles. But the cost of due diligence — which I'll assume to mean taking reasonable, well-established, tried-and-tested steps to ensure q

I would argue that software is different for other reasons. Most software developers/companies cannot be held accountable because changes in the industry are beyond their control.

For example, when engineers design and build, they have to contend with a variety of concerns. Most of these concerns are calculable, limiting, and realistic. As a simple example of the forces of nature, wind power is calculable and only occurs within expected limits. Things are built to withstand extreme winds. But there is a threshold -- we don't build to withstand 5,000mph winds because we know it just won't happen. Wind is wind, it increases or decreases, nothing more.

Software, on the other hand, has the problem of dealing (or not dealing) with unknown circumstances. Developers cannot know that in five years, the platform their product was built on will be obsolete and unusable. Products come and go daily, and support for these products fade just as quickly. Hardware also changes on a daily basis, making it impossible to stand behind your product, the same way an engineer does his. There is no professional obligation for software developers because there are so many unknown variables that come into play.

Here's another way to look at it using the bridge example. If an engineer 50 years ago built a bridge to support the horse and buggy, not knowing that the invention of the modern-day car was on the horizon, he cannot be held accountable for the bridge's collapse under the weight of multiple vehicles.

This is akin to software development. Developers cannot predict the future, consequently cannot plan for it, and ultimately therefore cannot be held accountable for it's failure.
Also... The other big reason is that a blue screen of death doesn't result in actual death.

Actually, depending on the context software is used in, it can quite quickly result in death. Planes and automobiles come to mind.

That's a damn good point. If cars were as fault tolerant as users want computer programs to be, you could pour soda into the gas tank and the car would filter it out, put it in a cup, and place it in your drink holder for you. The number of strange operating conditions that software handles gracefully is extremely broad, compared to a lot of other consumer products.

I would argue that software is different for other reasons. Most software developers/companies cannot be held accountable because changes in the industry are beyond their control.
For example, when engineers design and build, they have to contend with a variety of concerns. Most of these concerns are calculable, limiting, and realistic. As a simple example of the forces of nature, wind power is calculable and only occurs within expected limits. Things are built to withstand extreme winds. But there is a th

I agree, fortunately real engineering disciplines have a sense of scales. So we usually don't (over-)over-engineer. Trying to use the same design for vastly different scales if an illness of the programmer, not the engineer.

Let us also not forget that the ultimate responsibility for a major team effort failing is usually managerial. There are processes that any professional engineering team's leadership puts in place in order to make sure the end result is as expected. That's because nobody is perfect and mistakes get made. So, it's easy to pick on a single individual, like the aforementioned civil engineer. One should ask why there was no proper design review (and if there was, why did they sign off on it?) In any event, a properly structured real-world project has layers of checks and balances. Modern engineering projects may have hundreds of individuals working on them, and for anything other then chaos to result, there has to be direction, there has to be oversight, there has to be management.

When you get right down to it, when a big project fails the grade (like, say, Vista) it's the people who get the big paychecks that should be held accountable. That's why they get the big paychecks! They're supposed to make certain that the development and support staff are competent, and set up systems that provide adequate assurance of quality. Failure to do that is not the fault of the individual engineer, but is a systemic issue with all the fingers pointing to the top. Managers (particularly incompetent ones) will usually find a scapegoat in the form of an engineer, who they can point to and say, "See? It was all his fault!" That conveniently ignores that fact that, even if said engineer is a total bumblefuck... it was management that hired him in the first place, and failed to manage him effectively in the second.

But software is different, for some reason. For example, do you see that happen with Microsoft? Hell no! If Microsoft were held accountable for its software like Engineers are, the company would have been sued into oblivion and Bill Gates would be in jail for gross negligence. And so would the responsible parties of every other software company

Software is different, in that small mistakes often have very large and far-reaching consequences. When designing software, you also have to deal with far, far mor

Software is different, in that small mistakes often have very large and far-reaching consequences.

Ha! You want to talk about small mistakes? Here's a small mistake: a contractor didn't want to bother threading a few nuts up a really long rod, so he cut the rod into three pieces and attached them to the beams they were supporting separately. No big deal, right? I mean, I wouldn't want to have to spend hours spinning nuts on a rod either!

Well, guess what: it killed 114 people [wikipedia.org]! So don't go telling me that software is "different" because of small mistakes. Because it really damn well isn't!

And another thing-- my company decided that they wanted to go from 99% bug free to 99.999% bug free software rollouts (a bug costing us perhaps $1000 per minute of downtime).

The result is that our software takes a minimum of 8 to 12 times longer to roll out than it did before. It is now so slow that our developers are starting to lose their skill set because there is so much downtime.

Where before we could roll it out-- suffer the "$30k" loss, fix the bug (which takes weeks of testing but only a few minutes in production to flush out), and put in a fixed build in a total of 2x the time.

And the real kicker is that we STILL get bugs in production after all that testing because the best test site in the world doesn't simulate 70,000 users hammering on the software. (and the company doesn't begin to pay for the "best" test site anyway).

The engineer who messed up that highway is responsible for his mistake (thus the court case) and, if he messed up badly enough, will be censured by his professional organization. The engineer who designed your car, if it was one (it may not have to be in that case) is also responsible if, say, your brakes fail and you die or are injured because of a design flaw.The "software engineer" in the article, who sounds more like a programmer, is not.

Sure. I was trained in aerospace so can at least tell you about some of the requirements of engineering. In the military there are many 'Mil specs' that must be met for any aircraft design (although less so for autonomous, unmanned vehicles). Within any company there are standard guidelines for the standard tolerances for various design attributes (such as tolerance for flatness, angle accuracies, cylindrical attributes, etc.). For civilian aircraft design there are many similar, but sometimes different

Yeah, show me where the software engineer's signature is from the guy who guarantees that the software won't kill anyone.I guess it depends on what he means by rigorous, though. At least in most kinds of engineering the problems aren't unexplored, so you have some guidelines to work within that pretty much guarantee your building won't catch on fire.

But there's a huge difference between guaranteeing something will work and making something that pretty much works most of the time, we think. Comparing the t

I'm a student of both civil engineering and computer science, and I'll tell you this: most people who call themselves "software engineers" are wankers who have no idea what Engineering actually means. So they have some UML and unit tests? Well, that's wonderful -- at least they're not just randomly bashing on keyboards. But it ain't Engineering.

So what is Engineering, you might ask? Well, here's a clue: being an Engineer means that when you screw up, people die. It means that the thing you're making has to

Until some real bad judgment sees you putting a small plastic part into the door handle, making it potentially hazardous for children - we've seen it before and we'll see it again. Or maybe during all the cost cutting the company opts for shoddy plastic that deforms and gives off toxic substances in a particularly hot summer. Or maybe the plastic becomes brittle over time, allowing it to snap off and form sharp edges.

I was personally involved with plastic component design with car radiators - the number o

Depending on the choices I make during my next year at uni, I may gain the right to legally call myself a chartered engineer. I probably won't be controlling spaceships or managing a nuclear power plant (I'm doing a cybernetics degree) but I'll be no less an engineer than anybody else who has legally earned that right. Civil engineers take many forms [wikipedia.org], not all of which are necessarily directly responsible for hundreds of lives (Acoustic engineering for example) but all of which may play a role in a larger sy

engineers take many forms [wikipedia.org], not all of which are necessarily directly responsible for hundreds of lives (Acoustic engineering for example)

You'd be surprised what kind of dangers engineers from different disciplines have to face. Remember the ICE high-speed rail crash [wikipedia.org] from a few years back? That crash happened because a resilient wheel came apart, which derailed the train. Resilient wheels are used as a noise control measure for train wheel/rail noise - thet are designed and spec'd by acoustical engineers.

being an Engineer means that when you screw up, people die
I'm a computer scientist, AKA as "software engineer" in 90% of countries I worked in.
If I make a mistake and insert a wrong value in a database, or someone didnt test something correctly, thousands can die in a train crash. Is that engineering?

It's not Engineering, it's not even science unless you're doing theory, and compared to either of those things we're still bumbling around in the Dark Ages.

Most CS research (especially networking) relies heavily on the scientific method. It's not a 'natural' science like Biology or Physics, but the methods are very much the same. TCP/IP would not be where it is today if not for heavy experimentation and analysis.

There are plenty of qualified engineers designing non-"life or death" products that wouldn't agree with you. I'd hardly say a using a toilet will turn into a life or death situation, but I guarentee you some engineer took great pride in his crapper. You can say this about thousands of other common things; cell phones, car climate systems, radiators, fans, key pads, etc.. Some software is related to life-or-death (you gave some examples), but much of it isn't. The same can be said for engineered products. I

Ask people what professions they think require high responsibility, and they might say something like "doctor." Well, doctors really don't have all that much: unlike Engineers, they can only kill their patients one at a time. Engineers kill people in big groups.

Hmm. I thought you said you are studying civil engineering, but it sounds as though your career objective is combat engineer. Surely you know the distinction: "civil engineers build targets, combat engineers destroy them". But I think I get the idea: you're saying that engineering differs from computer programming in that engineering is an activity that has real-world consequences, while programming does not. So if you're a programmer working on, say, the targeting and guidance software for a cruise missile, then you're completely harmless. I work for the software group of a company that makes lab instruments that analyze yucky bodily fluids to see what's wrong with people. Those instruments are controlled by...software. (It runs on Windows, don't tell.) If I screw up, and a few hundred cases of Hepatitis C go undiagnosed before someone notices, well...I probably won't have killed too many people. After all, I'm just a harmless programmer...

I actually agree with you—the title "Software Engineer" is pretentious.
I disagree with your apparent belief that programming differs from engineering in that only engineering can have serious—even fatal—consequences. As I tried to show with my examples, the way in which computer programs function—or fail to function—can have serious consequences as well. So what is the difference between engineering and programming?

You might invert the question: why would anyone think they're the same? I think it's correct to say that, in the most general terms, engineers determine how to construct or arrange materials to fulfill a specified purpose. In doing so, they manipulate quantifiable entities—such as the strengths of materials, the distribution of stresses, the known limits and characteristics of varying methods of construction as determined by empirical study, and so on. Programmers don't do anything like that. Programmers write code, and code is an application of logic. You might say that programmers are like engineers who build logical machines, but that's mere metaphor. Computer programs don't break because the wrong type of steel was specified for one of the gears.

So where did the notion of "software engineering" come from? Maybe it's symptomatic of an unspoken insecurity, a fear that programming isn't a serious profession. Perhaps one source of this insecurity is that programming is still a very new item in the human tool-box, and we haven't quite decided which compartment to put it in. Moreover, programming isn't like any other tool we've had before. It resembles engineering in that the programmer does build something, though no materials are used in the building. It resembles mathematics in that it's logical, but it isn't bound by mathematical rigor. You can't "prove" a program—except perhaps in a—completely impractical—theoretical sense. (Of course you can test programs, and rest assured that where I work, we have very thorough software design and testing protocols.)

And now the next contentious question: are computer scientists really scientists?

Sure, make light of the industry. I've been writing safety critical software for the last 7 years. You can thank the software engineers that wrote the fuel injector firmware for the turboprop on your plane for properly engineering it to always work. And while you're at it the software engineers who wrote the code running the life support systems in the ICU also deserve some props.

Not all of us work in a fault tolerant environment. Because we do our jobs well, you don't hear about the latest scandal on Slashdot. This would explain the lack of articles about software bugs causing airbags in Ford cars failing to deploy. I know you were just joking, but to some of us, software engineering is serious business.

I'm obviously going to be modded down for this, but what does this blog post do on the front page of Slashdot? I mean ti's not news, it's just a guy with a job like another telling us his life. Surely that may be relevant to some, but that's just a blog entry about someone's life among others, so what the hell is it doing here? Is that guy pals with ScuttleMonkey?

I mean ti's not news, it's just a guy with a job like another telling us his life.

It seems you have a rather narrow definition of news. Newspapers have fluff pieces about peoples lives all the time. Newspaper columnists are known make an entire career out of doing what you just describe.

It may not be any good, it may be crap (I can't read the thing as it's slashdotted), but just because it's not "something that happened today or yesterday" doesn't make it "not news".

Using a bridge-building analogy, in my opinion the software development phase is akin to designing the bridge. You've got to present what you want it to look like and how you want it to function in a visually appealing way but the exact details aren't your concern, that's up to the engineer to figure out. In the software world, the computer plays the role of the engineer. It's up to the computer to figure out how to implement what you've described. Therefore, Canada has it right. Software development isn't

or you can make the analogy comparing it to engineer/construction worker. the software engineer writes the blueprints and what not, the computer just puts it together.

analogies are great that way. you can make almost any argument if you really try. Seeing as how the definition usually comes down to one who uses science and practicality to solve problems, I think engineer can apply.

Canada does have software engineers. The difference is that you can't just decide to call yourself a software engineer without having the proper credentials. Just like you can't call yourself a doctor if you aren't a doctor.

If they engineered bridges the way they "engineer" software, they would just take parts of existing bridges plus random scraps of custom metal and concrete, duct tape it all together, and test the result to see if it crashes.

well, depends on the software in question. common software development isn't engineering by a long shot and should never be referred to as such.

if you're something where actual engineering principles and standards need to be and are applied, like the software for airliner's control systems or medical equipment, or something else in the "if this fucks up, people die" realm, that can definitely be called software engineering.

I've ran across EEs, MEs, CEs, you get the idea, here in the US that insisted that software coders, Computer scientists, or LAN engineers were not engineers. Basically, they said that their profession was based on physical laws - engineering is applied physical science - whereas CS is based on man made rules just like grammar and writing. And you don't see writers being called "language engineers". Snobbery? Maybe, but I kind of sympathize with them becau

More to the point, an engineer has a degree from an accredited engineering program and has passed the exams and other professional requirements for an engineering license. The word has been diluted mostly by people who not only have insufficient technical understanding to practice in the fields to which it is applied, but even to distinguish those fields from other technical fields.

I've met software engineers that I'd be happy to refer to as "software engineers". I've also met code-monkeys that will happily claim "software engineer" status. Canada's upholding some standard for the term engineer is spot on. Get a degree and proper accreditation, and then you get your title. This may sound egotistical, but it's unfortunate that, here in the US, describing myself as an "electrical engineer" distinguishes me only slightly from the "sanitation engineer" that hauls off my recyclables once a week.

The way I see it, A software Engineer is actually tasked with designing an application based on the requirements given and with knowledge of the software tools at his/her disposal. A software Engineer may not ever write single line of code, though he/she should be knowledgeable on the particular language and development framework chosen. A Software Engineer would probably have a strong background in programming, and like most engineers, probably still likes to tinker around with the technology.

In Canada the word engineer is reserved for someone with not only significant technical and mathematical knowledge who has a degree in engineering but also takes legal responsibility for his work and is monitored by a professional association.

We have sanitation engineers too, but they're definitely not the guys who ride on the back of the garbage truck.

I just returned from a seven weeks stint in Europe as a software engineer. My company sent me there because according to my boss there are limits on software exports from the US - they found it cheaper and more time efficient to do all the affected coding in Europe, and thus avoid these limitations.

My company is incorporated abroad, our servers are abroad, and I'm not a US citizen. Thus, the only limitation we've had was for someone physically sitting in the US and writing the code, which we avoided by shipping me abroad.

Who tagged this Pompous... Beat me to the punch. I write code, it's my job. No more, no less. To try to give it esoteric meaning beyond what it is reaches a level of loathing that even I am not going to try to comprehend. It's a job! We may want to make ourselves seem more important based on our position because of the tech around us and being able to tell people "no" but in the end we're just beating the next level of rocks together.

You are not allowed to call yourself a "software engineer" in Canada, not because the discipline lacks rigor, but because it lacks professionalism.

A profession is formed for the public good, in order for experts in the field to supervise, regulate, and discipline one another. In Canada this is carried out through non-governmental professional associations, and there is one engineering association per province. It serves public safety well and is an excellent alternative to both "buyer beware" and governmental intervention. Doctors, nurses, lawyers, and teachers are similarly regulated.

I'm personally sympathetic to the professionalization of software engineering. Basically this would mean that you would need a license to practice, all your code would be signed by its author, and the association would discipline any software author who wrote bad software, either maliciously or accidentally. Although it means hobbyists could no longer tinker, we are at the point where that hobbyist tinkering could have significant implications for the international system of computing infrastructure. Why should unlicensed software authors be any different from unlicensed doctors? Both can cause harm; in the former case, potentially more harm.

When's the last time you signed an agreement to hold a car manufacturer or builder harmless in case their product broke down or fell apart? Amateur software authors produce some of the most important and well-tested code used today, while the professionals at, say, Microsoft, have a proven record of producing insecure crap. How would licensing change this?

While there may be a professionalism problem, it seems to me that there is a rigor problem as well.

When's the last time you signed an agreement to hold a car manufacturer or builder harmless in case their product broke down or fell apart? Amateur software authors produce some of the most important and well-tested code used today, while the professionals at, say, Microsoft, have a proven record of producing insecure crap. How would licensing change this?

In Canada, corporations that provide engineering services are required to hold a "Certificate of Authorization". This certificate can be suspended or rev

Further pedantic correction: The degree (from an accredited institution) is not required if you're willing to write many many MANY equivalency tests. Basically, write the final exam for every course in 4 years of University, and you don't need to have a degree to become a P.Eng.

And the ring is just for tapping against beer bottles. Everyone knows that:)

A profession is formed for the public good, in order for experts in the field to supervise, regulate, and discipline one another.

That's funny. I always thought a "profession" had more to do with social class than anything about supervising, regulating, and discipline. This is the first I've ever heard such a formal definition, with rules set forth, etc.Doctors, nurses, lawyers, and teachers are similarly regulated.

So you can't call yourself a "professional" unless you've been regulated by the government,

Although it means hobbyists could no longer tinker, we are at the point where that hobbyist tinkering could have significant implications for the international system of computing infrastructure. Why should unlicensed software authors be any different from unlicensed doctors? Both can cause harm; in the former case, potentially more harm.

Doctors always work on people, and will harm/kill people if they screw up. Software people can only mess up whatever their software is given access to mess up. Hobbyist t

In the US if someone who writes software wants to be recognized as an Engineer, they can go out and get licensed as a P.E. (Professional Engineer). This license places the liability upon the engineer for the work they do and is not something which is given out as easily as an engineering degree.

Bullshit. Professions in the sense you speak are formed for the good of those people already in the profession. It allows them to control who can compete against them, both by giving them a say over who can join, and by getting the government to restrict what people who haven't joined can do.

Although the "professionalism" and "public good" argument you make has been used ad nauseam, and it has a certain attractive logic to it and seems like it should be true. But, there is very little quantitative evidence available, and almost all that there is indicates that government sanctioning of professions has had absolutely no positive impact on the quality of the services rendered by those professions, and there is considerable evidence to suggest that it may have degraded it (although it's difficult to determine causality given the number of factors that go into something like that). In other words, they do absolutely nothing to protect the common good over, and they may harm it.

Government sanctioning and licensing of professions is completely about control and prosperity of a particular group. That's now how they're justified and you won't find it in the charters or enabling legislation, but it's the reality of the situation. They are lobbying groups and industry associations all rolled up into one, with quasi-governmental powers to boot.

Although it means hobbyists could no longer tinker, we are at the point where that hobbyist tinkering could have significant implications for the international system of computing infrastructure. Why should unlicensed software authors be any different from unlicensed doctors?

Your statement shows a fundamental misunderstanding of the craft. Basically, every really incredible programmer/developer/software engineer got that way by tinkering. Not by taking 60 credit hours of programming classes. It's the countless hours of trying things out and figuring shit out that got them good. The classes, if they were even taken, provided a starting point. Anything that discourages tinkering prior to or in addition to formal training would have a dramatically negative impact on the "international system of computing infrastructure" because it would drastically reduce the ranks of those who actually make all the stuff work.

While I actually have issues with licensing of Doctors, I'll point out one very serious and very obvious difference: You an code on your own computer -- tinker if you will -- and have absolutely no chance of hurting anyone else. You can't exactly practice surgery on your friend safely. You can study anatomy all day long, but without being able to work under a doctor while cutting into a patient or diagnosing a difficult case, you're likely to do far more harm than good no matter how much knowledge you have shoved into your head. They are not comparable cases; there is some basis for licensing of doctors, absolutely no rational one for licensing of software engineers unless you are completely ignorant about how good coders become that way.

Now, if you want to talk about specific accreditations for programming in fields where there is a high risk of harm, such as coding for the FAA or NASA or military, I'm willing to be slightly more sympathetic to your argument, but am skeptical that it would guarantee or even improve the quality even in those fields.

To become an accredited engineering program in Canada, there has always been a strong requirement for a scientific background. This first created problems for computer engineering programs in Canada to become accredited, so they added courses on things like the physical properties of silicon, etc. to meet this requirement. Electrical engineering, of course, has thermodynamics, etc.

Software engineering has this problem of needing to incorporate science courses into the curriculum. Also, the field of software engineering isn't considered to have matured *as much* as more traditional disciplines. I'm pretty sure that there are accredited programs and you can be a software engineer in some provinces now. These things don't happen overnight.

I would like to have as much confidence in a piece of software as I do in a bridge, but we're not at that point yet. I do think we're getting closer. At this point, very little software is really "engineered" in the rigorous sense. Software that is tends to be much more expensive, and much more reliable. Go figure.

Most software buyers don't want to pay the extra expense for the extra quality at this point. Of course, if you're purchasing a flight control system for an aircraft, you probably have deeper pockets and more stringent requirements.

Just as an example, in Quebec, the ETS has an accredited software engineer program. I didn't take it, so take the following with a grain of salt, but I had a few friends who did... To enter, you need to already have a CS background of some kind (be it from another school, work experience, etc) so they can give you credit for the basic CS classes, and they replace them with the engineering classes (and also allows them to start a decent bit further... I don't know if its still that way, but my friend's first

I never knew people coveted to be called engineers. Class conscious England clubbed the Engineers with tradespeople and snubbed them regularly. Even in USA I am not sure people really took the engineers seriously, mostly mistaking them for railway locomotive drivers. Not many people with engineering degrees sit for PE examns and qualify themselves as Professional Engineer. Those who do, seem to be mainly expert witnesses for defense for the ambulance chasers.

Not many people with engineering degrees sit for PE examns and qualify themselves as Professional Engineer. Those who do, seem to be mainly expert witnesses for defense for the ambulance chasers.

Nonsense. It just depends on your discipline and industry.

In the USA, PE licensing is all but mandatory in the Civil Engineering field. It's very helpful in electrical engineering if you want to be a power distribution guy. Mechanical engineers can stand to have a PE license if they're going to be doing HVAC work. In other words, if you're going to be an engineer in construction, a PE license is very important to have.

If you're contracting out a big dollar engineering project, it's common to require a

When you are a halfway decent programmer and do it professionally, you will come across a wide range of projects. And what happens wich each new project? In a matter of days or 1-2 weeks you gotta acquire the knowledge of your new problem domain. And that is very often a problem domain others spend years to study and get a degree, yet as a software engineer, you gotta be able to understand the problem domain good enough to automate it. T means you must be able to understand all the nomenclature and the stru

"software engineering" or whatever the hell it is, is something a smart 10 year old can learn and do as well as some guy who has 40 years in the field. you will of course here blather about knowing about N gates and P gates, UML and use caseas if any of that crap really matters. seriously

not having htis matter is good, because unlike a real chemical engineer, us IT plumbers, or dot com hot air wranglers, or whatever the hell we are, don't have to play with chemicals that give us cancer

I was unable to read the article, due to Slashdottery, but from the quote, I think Mr. Wise is failing to understand what "engineer" means. There's no minimal competency required to slap "Software Engineer" on your card, there's no license board that will certify your competence, there's guarantee to a given customer that you have any clue what you're doing, and you are ultimately not liable for damages, in most cases, if you are producing defective work.

It's not that software engineers don't care, or that we're somehow inferior. It's that there's no way to learn software engineering the way Engineering disciplines are learned. You can teach a civil engineer to make a bridge that will stand for 200 years, but there is no educational program in existence that can even begin teach a software engineer to design flawless software. That discipline simply doesn't exist. I can use mathematics to design a concrete structure that is 100% guaranteed to float. I cannot use mathematics to design billing system software that is 100% guaranteed to address all requirements. A hodgepodge of algorithm analysis, best practices, design patterns, gut instinct, pretty diagrams, and programming experience does not an engineering discipline make.

On top of all this, people make demands of software engineers that no one would make of an Engineer. Imagine that a construction crew is halfway through building the bridge which you designed, and then the government comes back to you, and tells you that no, they've decided that really they want the entire bridge to be two feet to the left. Oh, and they don't like how the concrete looks, so could we use granite, instead? Or, imagine that a car company has tasked you with creating a concept car for the Detroit auto show, but they don't quite know what it looks like or what it should do, beyond some vague hand-waving, and they're hoping that you can iteratively evolve a concept car for them, so they can give feedback as you work, but they expect this all to happen for the price of building one car. Then, they come back two months later, and tell you that they've decided that they're skipping the auto show, and instead, they need it to be road legal and ready for production by July.

So, yes, we may call ourselves "software engineers," but we're not really Engineers. We have a lot of uncertainty in our lives, and in all fairness, I, for one, don't want the liability.

- Sorry about the site being down. Its probably not a coincidence that I made Slashdot AND my host (which, to be fair, survived a Digg-rush awhile ago) is having troubles. I'm on the horn with them right now.

- A few people, who likely didn't make it to the site, like to make broad generalizations about geeks of this sort not having sex. I'd like to point out for the record that I'm married, have one child and another on the way. This suggests that I've had sex at least twice. And my wife is very beautiful.

- The intent was not to gripe about Canada's standards for the term "engineer." I only pointed that out the difference between my home country, and my current country of employ. I prefer the term "software developer" myself, but it doesn't really matter to me.

- The intent was also not to be pompous or fuel my own ego, it was to describe, as eloquently as I knew how, what most of us here on Slashdot are. Although the stigma is going away, us geeky types tend to be considered only that: geeks. When really there is art and beauty to what we do. I'm not even as skilled a programmer as I imagine most are, but I wanted to lend my prose to our art because I believe it is valuable. But flame on, if you must!

Thanks for reading, hopefully the site will be back up soon! I'd copy and paste the article text here, but I wasn't expecting this and don't have an offline copy!

>> I'd like to point out for the record that I'm married, have one child and another on the way. This suggests that I've had sex at least twice.
Actually, it suggests that your wife has had sex at least twice; it doesn't say anything about you.

The inability for random people to call themselves software engineers in Canada is because the Real Engineers objected to the proliferation of people with MCSE's and the the like doing a discredit to the standards of the profession, both in terms of training and work results.

So go to university for 4 or so years and you'll get the respect you crave. And the nifty IRON ring, much sexier then token ring any day.

Even if you graduate from a software engineering program at university you're still not allowed to call yourself an engineer. You have to get a Professional Engineer certification and join an engineering professional association.

Computer science has a few outcomes. You can be a code monkey, or more likely a systems analyst or such. Or you can become an actual scientist by going to grad school and going into research.

So go to university for 4 or so years and you'll get the respect you crave.
I graduated with a degree in Electrical Engineering. My job title can be Software Engineer (though it could be even if I dropped out of High School here in the U.S.). However, I cannot call myself a Professional Engineer even with my degree because I would have to go spend about $5,000 on a certification program, in addition to the $30,000 or so I spent on college.
Interestingly, even if I did get the Professional Engineer certific

Flipping, charring, till operating, cleaning and eating the shit from customers while keeping a smile on your face. All jobs require multiple skills.

Silly whining poster probably just got out of college and is used to mommy and daddy telling him he's the greatest. Now in the real world he's just another bottom-of-the-pile programmer. Life: get one!

And that is also why you should never be allowed to call yourself "software engineer". In a single short post you have demonstrated a contempt for regulation, law, clear communication, and honesty, which are all required for a Professional Engineer in Canada.

Despite knowing the regulations and laws behind the matter, you choose to willfully violate them, not to mention potentially defrauding others by impersonating a legal engineer.

Like others have said in this thread, being an engineer is not about bei

Not a flame as such, although much of what you say is flameworthy. You lack clue.

"The professional association allows them to hide behind a large entity, with deep pockets, such that any litigation against a single individual, is futile."

Um, no. The Professional Engineer Association of which I am a member has about 18000 members and we pay about $225 per year. An annual budget of $4 million is not "deep pockets" by anybody's definition, at least not when stacked up against corporate clients with several orders of magnitude more money. More to the point, the Association doesn't spend _any_ of its money defending engineers against litigation for faulty work. They do spend it pursuing discipline against incompetent or unethical members. The record of discipline against members is public, you can usually find it on their websites. Try APEGBC, PEO or APEGGA for examples. Every month we get to read about a handful of cases where somebody is disciplined for substandard work.