Define -- "Software Engineering"

2nesser asks: "How do you define the term 'Software Engineering'? Some see it as the implementation of the theoretical world of Computer Science, but isn't there more to it than that? Social responsibility, documentation, a program that works under precise, known conditions? Can you compare Software Engineering to other disciplines? What sets a 'Software Engineer' apart from the rest of the crowd?"

Comments

My definition

[pauljlucas]

Software enineering is designing a software system. It need not only be the "big picture," but can also be the design of concrete things like classes, APIs, file layout, protocols used, etc. Contrast this with programming which is the mere coding of a design.

The term developer was coined (IMHO) by programmers who didn't like being referred to as programmers because it has an implied "lowly" in front of it or comes off as generally nerdy.

Going back to the rest of the original question:

... a program that works under precise, known conditions?

It would be a minor miracle to know conditions precisely. What you do know are expected conditions and you want the software to work under them. But there are an infinite number of unknown conditions. What you would like to happen is that the software either flag the conditions as inappropriate and refuse to act or fail gracefully.

I'll try

[WolfWithoutAClause]

Software engineering is when you are consciously having to trade things off; and you do it (mostly) successfully.

The things you typically trade off are speed, manpower, memory, diskspace, cost, delivery, algorithms, complexity etc.

If you're not trading things off, then you are a technician, not an engineer.

Definition

[Anonymous Coward]

Software Engineering is the process of creating a quality system that does what is specified, in time and within budget.

I am a 4th year Bachelor of Software Engineering Student at Monash University in Melbourne Australia and that is pretty much the standard definition that is drummed into us constantly.

Hasn't anyone read a textbook?

Software Engineering...

[Quantum Skyline]

...is the application of engineering principles to software design and computer science problems.

Software Engineering != Computer Science.

My university [which will remain nameless] supposedly got in trouble with Professional Engineers Ontario because its Computer Science grads were calling themselves "Software Engineers" when there was a Software Engineering program running. After that, computer science was forked into computer science and "Software Design".

In Ontario, its illegal to call yourself an engineer of any kind without going through an accredited program. MCSEs are allowed to call themselves "MCSEs", and not "Microsoft Certified Systems Engineers".

Software Engineering != Programming.

The reason why it gets no respect is because its new, hence the earlier post that it is simply "akin to sanitary engineering" is just dead wrong. The argument that software engineers are sloppy "because if we built bridges the way we build software" is also useless for the same reason. Let the practice of Software Engineering mature.

Regulations are less than 10 years old. Imagine what Mechanical Engineering or Civil Engineering was when it began. Does anyone remember the building that twisted when subjected to wind?

Software Engineers != Programmers.

The bastards who wrote Slammer, Nimda, SirCam, Code Red, Klez (need I go on?) are programmers. Anybody who writes a program for release is a programmer. Software Engineers are obligated to produce good code (and other design documents) because they are subjected to a regulatory body (similar to the Bar for lawyers). This is at least true in Ontario.

So what is Software Engineering again? Take computer science, programming, engieering principles, legal obligations and ethics and combine them.

Re:no such thing

[Anonymous Coward]

Other organizations have better ways - for example the Loral Space Shuttle Software Group operates at CMM level 5 and produces the code with error levels on the order of 0.5 errors/KLOC where good quality commercial software runs at an average of 20 errors/KLOC.

Are you sure this level of performance isn't just due to a coincidental collection of "talented individuals"? I.e., could you pull a random group of CS majors off the assembly line (heh) and train them in these methods, and achieve the same results?

Unfortunately about 90% of the software industry is operating at the level of Calvin Ball.

Why do you suppose that is?

Re:More Precise

[moncyb]

I think you are wrong. Remote root exploits are caused by much bigger errors than "0.1 degrees". Oversimplifying, such security bugs can be set into two classes:

1. No bounds checking. Buffer overflows and unknown strings in printf's format parameter are more like the architect is off by 45 degrees, assumes the beam can take twice it's rated load, and only takes the building's weight into account. So if a cat jumps on the roof, then the whole ceiling will collapse.
   
   
2. Silly stupid mistakes like "off by one" errors. This is the same as if an architect made a single beam 1 foot shorter than it should be. Assuming redundancy and an otherwise good design, the cat jumping on the roof probably won't cause a problem. There may be a problem if someone places an object that weighs the same as the architect designed for, but if she overcompensated on the design such that, say the roof was rated for 2200 lbs, but designed for 3000 lbs (as should be done), then there may not be a problem. These errors will cause problems (like crashing after a syscall is made 2 billion times), but are not nearly as bad.

The first problem should never happen with an experienced and competent programer. That kind of "mistake" is reckless programming. The second does happen, but designing the entire system properly will minimize the damage these errors can cause.

The heap and stack pages should not be allocated executable by default. If a special program needs the ability to write and execute code itself, it should use a special memory allocation routine. Executable code pages should not be marked as writeable. All programs should not be run as root, or if need be, run as root and drop to normal user status as soon as possible. For those programs that do require root, the kernel should be evaluated to see if a permission system can be used to eliminate this need. That way, a program which needs raw access to the video card can't mess with critical files or deactivate the door locks to your top secret room.

The kernel needs similar checks. High level things such as the TCP/IP stack should not be able to modify any I/O ports or hardware memory, only the network card driver should. If possible, hardware drivers should not be able to access any device they don't cover. For example, the network card driver shouldn't have access to video memory. In fact, a permission system should be applied to parts of the kernel. TCP/IP, network card drivers, video card drivers don't need to access hard drives, filesystems, or door locks at all, therefore they should be denied access wherever possible.

Architects and various engineers all design so that one minor mistake or unexpected event will not cause their building/device/whatever to come crashing down. Sometimes a manufactured part doesn't exactly conform to spec, many engineers know this. If your calculation shows a point will have 100lbs of stress, you can't expect a bolt rated for 100 lbs to be good enough. It may have a defect where it will only hold 90 lbs. Someone may put 110 lbs of stress on it. All sorts of variables can and do happen. That is why a good engineer will design beyond the spec. Software needs to be the same way. Yes, doing these precautions will cost extra memory, cpu time, and coding time, just like these precautions cost extra money, space, and design time in other fields.

Re:working definition

[sql*kitten]

Engineering is the act of constructing a system to meet said requirements.

You are mistaken. Civil Engineers design a skyscraper, construction workers construct it. Mechanical Engineers design a car, assembly line workers construct it.

A software engineer spends 80% of his time on requirements capture, analysis, design and documentation and 20% of his time coding. A programmer gets his instructions from an engineer and spends 95% of his time programming (and the rest goofing off on /.).

In any mature industry, actual implementation is semi-skilled labor at best.

Re:What an ominous question...

[neitzsche]

Dear AC,

Please don't post as AC; I almost missed your reply.

That is a good point. I wasn't trying to go in quite that direction but now that you mention it...I do think that programming naturally progresses to engineering. That is, a person will either 'get it' or not. If not, then they will not be programming long. But if they do, then they will accumulate their own bag of tricks over the years, and gradually appreciate and adopt engineering principles.

So in that context, yes, I would consider a senior programmer equivalent to an engineer trainee.

I was trying however, to point out that the term engineer is more often used as a cludgeon by bad managers.

As a legal term

[Lumpish Scholar]

To call yourself an "engineer" in several of the states in the U.S., you must pass two licensing exams. Texas in particular has been known to come down hard on people who use that title without taking the exams and being a licensed engineer. That's why I call myself a "software developer" instead of a "software engineer" if I can help it.

First, a software engineer must be an engineer. I have a bachelor of science degree in physics and master of science degrees in mathematics and computer science. In most states, I cannot even take the licensing exams and never will be able to unless I go back to college and get a bachelor's degree in some engineering field from an ABET-acredited school. (In some states, anybody can take the exams. Either way, my "liberal arts" degrees don't count for anything. Some other states consider math, physics, and chemistry bachelor's degrees acceptable, but not computer science degrees.) At any rate, the exams cover general engineering: electrical, chemical, civil, mechanical, industrial. The goal is to ensure you're a well rounded engineer.

Second, some states (at the urging of the local professional engineering societies) think any "engineering" effort must have at least one licensed engineer. This is a bigger deal than it might first appear.

Sure, I'd like to see someone who knows civil engineering involved with every non-trivial bridge that's built, and if Union Carbide built a chemical plant next door, I'd like a chemical engineer to be checking things out. (See also below.)

However, sometimes (Texas again) embedded software development projects are considered close enough to "engineering" to require, under law, at least one licensed engineer to be involved. Those civil and chemical engineers are considered qualified; with a master's degree and twenty years of experience, I am not.

There are a handful software professionals who are licensed engineers. (Want to guess what state they're in?)

Having said all that, let me say this. All the traditional engineering fields have universally understood, univerally accepted bodies of knowledge, usual captured as some kind of code (as in "building code"). That's why I feel the way I do about bridges and chemical plants. On the other hand, while most individual software engineers think they have such a body of knowledge, no two agree on what it is. There is an effort to define this; a draft version "is ready for field trials for a period of two years."

Even a school that offers a "software engineering" degree says, "There is no universally accepted definition of software engineering, though there are elements of a forming consensus."

My humble opinion? Engineering disciplines have with good mathematical foundations: here's the equation for the tensile strength of steel, here's the formula for voltage as we increase power. Software development efforts do not have such a foundation. Some attempts have been made to provide one, but they're almost never applied.

P.S.: I do not live or work in Texas.