Slashdot Mirror
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?"
Software engineering is about being able to perform software development with repeatable and predictable results.
Software Engineering is about designing and specifying how a software system should work. A good Software Engineering process should be repeatable and reduce the amount of restructuring needing to be done later in the projects life time.
From some takes on it, mainly the P.Eng. (http://www.peng.ca) certification for engineers is what it takes to be a software engineer. Ergo by that all the requirements and responsibilities of a P.Eng. are involved.
ICQ# : 30269588
"I used to be an idealist, but I got mugged by reality."
I always thought the term Software Engineer was a term akin to Sanitary Engineer.
The word Engineer used to connote quality, rigor, someone who builds things that last. Engineers design buildings, and bridges, heavy haul trucks. Things that last for 20 years or more. As software developers we are more like artists. We design the tools that suite the latest fashion. Most software is trash in less that 3 years.
Prove me wrong.
Simple: a very, very, very sloopy engineer. Can you imagine architects planning buildings like we do software?
Code poet, espresso fiend, starter upper.
I'm sorry, but there's no such thing as Software "Engineering".
I have a EE degree but I work as a programmer now. Writing software bares only a superficial resemblence to any other engineering discipline.
Other engineering involves solid, proven, time-tested formulas and patterns, and can almost always be stripped down to "first principles" like the laws of physics.
Writing software involves re-inventing the wheel for every project, constantly changing it, and constantly changing methodologies to try and put out software that actually works for a change (where are the books on "Extreme Engineering"?).
In 100 years, Software may be specified, designed, built, and maintained just like bridges or radios, but not now.
Right now Software is more like some kind of creative art merged with mathematics. "Design Patterns" is the only thing I've seen in computer science that takes a step toward being more methodical, like other disciplines.
Not trying to insult folks who write software, I just think it's such a new and changing field, the methodologies havn't crystalized yet.
Engineering is about designing/implementing a product that meets certain criteria, with certain resources.
It's about getting it done for a certain cost, in a certain time. It's about making sure that certain saftey considerations are taken. It's about making trade-offs.
In the end, the software engineer has to be able to deliver a product and stand behind it. He or she is responsible for the quality of the product. If a bridge falls down, the engineers are blamed. If a car breaks down (due to bad design), the engineers are blamed. Similarly, if a program fails in some critical way, the engineers should be blamed.
From a software point of view, that means that we need to be able to accurately predict the behaviour of software. We need to be able to quantify things about programs. But we also need to be able to trade-off the cost of development with the savings. For example, it's silly to spend millions of dollars to protect a $10 asset.
We also need to be able to make guarantees about the safety and robustness of the software. This, I think, is going to be one of the biggest challenges as more and more life-critical systems become computerized with common-off-the-shelf components.
Just think of a project like the Ariane rockets... They are great achievements in mechanical, chemical, and electrical engineering. Yet the maiden voyage of the Ariane 5 blew up because somebody re-used software written for Ariane 4. The failure had to do with a floating-point error that was impossible on Ariane 4 but that happened on Ariane 5. (Well, it's more complicated than that, but this serves my point). The blame for the failure lies squarley on the shoulders of the sofware "engineers". Now, current software engineering techniques make it difficult to verify that a program can not be re-used in a new environment. But when the discipline matures, it will be Software Engineers, and their tools and tricks, that ensure that mistakes like Ariane 5 don't happen again.
When I worked for a large government contractor, there was intense interest in having our division become SEI level 3 compliant (then level 4 the next year, then level 5 the next year.)
:-(
This question was one of the ones asked by management at the time. They knew then that they were are the mercy of the 80/20 rules:
80% of the code takes 20% of the project time
last 20% of the code takes 80% of the time
80% of the staff does 20% of the work,
20% of the staff does 80% of the work.
etc.
So they tried to reign the "heroes" in. They did so by trying to adapt the over-performing 20% - by limiting what and when they could do, so as to:
A) bring the 80% along and
B) make the 80% not look so bad/suffer from low self esteem.
That division of that company reorganized itself into non-existence in the last few years (it had 1,200 "engineers" when they started in on the SEI stuff.)
--
In my opinion, programming is most efficiently done by individuals, when they are properly motivated. Much of the discipline of "software engineering" practices are VERY good but tend to be taken too far the instant politics are involved. For example, code reviews are essential for production quality code, yet when they become required for the tiniest change they become bureaucratic nightmares.
In my experience, the term 'engineer' has only been thrown about as a political buzzword; sometimes to justify higher education requirements, other times it is used to scare end-users out of filing formal complaints and other times it was used to raise hourly billing rates.
But whenever the term was used, it meant someone was planning on having programmers (ahem, engineers) program less.
"God is dead." - Frederik Nietzsche
How do you define the term 'Software Engineering'?
-I use dictionary.com and you should too -- it has a good definition and links to others, check here
Can you compare Software Engineering to other disciplines?
-Umm. yes I can.
What sets a 'Software Engineer' apart from the rest of the crowd?
-I guess that would almost entirely depend on the crowd.
I have been looking for a job for the last two months, and having dealt with several HR staff and recruiters, I can tell you that software engineering means you have an MCSE and can help the marketing director figure out how to get Powerpoint Presentation to "Open the internet".
.NET, Web Services and eXtreme Programming.
It also has something to do with like
"Can of worms? The can is open... the worms are everywhere."
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:
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.If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
Software Engineering: Anything that has to do with designing or refining systems for utilizing computers
Repeal the DMCA!
What sets a 'Software Engineer' apart from the rest of the crowd?"
Programmers have to be a hell of a lot more precise. When anarchitect screws up and the floor is 0.1 degrees from being level, no biggie. When a progremmer makes a similar-scale mistake, say hello to a remote root exploit or two.
Repeal the DMCA!
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.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!""Software Engineering is defined as the multi-person construction of multi-version programs."
>What sets a 'Software Engineer' apart from the rest of the crowd?
A good start, of course, is a four year degree from the department of Engineering at an accredited university. BS Computer Science under the Department of Engineering. Not those wannabe MIS punks in the business college with their accounting and management classes, but pure hardcore unadulterated comp/sci classes including compiler design, queue theory, three semesters of calculus, two semesters of differential equations, some statistics, numerical methods, logic classes, maybe some physics (statics and dynamics) while they are at it.
Second, a touch of autism never hurts. Real hackers can read 700 page technical manuals over the course of a weekend and remember the location in the book of any topic.
Be able to express yourself in strange languages - real software engineers can think in incredibly abstract ways, seeing things in ways that others competely miss. See 'A Beautiful Mind' for more complete information. Real software engineers write recursive code, self modifying code, and can think in six dimensions without breaking a sweat.
Finally, the ability to empathize with the machine is essential. Feel what the computer is going through, understand why it is working or not working, understand where in the system the bottleneck is and fix it to make your computer all better.
Offer your employee his choice between a raise and a new computer and the software engineer will pick new hardware any day.
Glonoinha the MebiByte Slayer
.... I duno, reverse it. Cars have to be able to withstand at least a small crash and keep their occupants safe. They must meet minimum mileage standards. They come with a drive train and body warranty, at least for a few years. And if it breaks during that time or it takes more than three fixes to correct a defect, you are allowed a full refund under a lot of states lemon laws.
Ain't no software like that sold that I am aware of. Brand new software gets a full skate on most things and is sold "as-is" like a used car, not like a new one. It's usually not even warrantied to even get off the lot.
Maybe the reason that you don't seem to think that software development can be stripped down to "first principles" is because you don't have the educational background to know what those principles are. The basic principles taught to Computer Science students around the country are as mathmatically verifiable and repeatable as any other scienctific system (including physics).
Thinks like "Big O" algorithm analysis, data storage techniques, and compiler theory form the basis of Computer Science and provide the structural underpinnings for most of the software engineering methodologies out there today.
I consider myself a software engineer. I certianly do not re-invent the wheel for every project because I have been using the same methodolgy ever since I started programming professionally (OOP). While I am constantly learning new tricks, techniques and technologies, the "first principles" that I learned in school have not changed over the last 50 years of computing history, and they will never change, because they have a firm foundation in mathematics.
The desire to do it right.
You are being MICROattacked, from various angles, in a SOFT manner.
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?
...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.
One of the better descriptions or perhaps essay, to the principle of being a software engineer was in an editorial by Charles Connell in Dr. Dobbs several years ago. Why Software Engineering is not BS
Interesting note, while a Systems Engineer for a top two IT company, we were told that they would be renaming the Architects. It appears that some words (Engineer, Architect) have legal meanings in some states. Apparently in some states you cannot call yourself an engineer unless you can prove certification by a standards body.
IANAL, but I would be interested in hearing from one on how that gets resolved.
Locate, if you will, the Mythical Man Month by Fred Brooks. Laugh as you read about how you had to pay money to reserve 4k of memory. Cry as you realize that what was true about Software Engineering 25 years ago is still true today.
Management does not like cowboys. When they say "BUILD ME SOFTWARE RAAWR" they usually want some sort of estimate of when the software is built, but more importantly they want to know what the likelyhood of it being built is. Single programmers cannot build large software on their own, so (large) teams of programmers must efficiently work together to get things done. Software Engineering is the who/what/where/when/how/why of building large software with large numbers of people.
[o]_O
I'm new to this! I know that a troll is someone who likes to incite an online "riot". What is the definition of "flame-bait"? Thanks in advance...
Listen to Live FM Radio
http://www.wikipedia.org/wiki/Software_engineering
Programming within certain fields can certainly be broken down into known variables. If you are programming a DB app, for example, you'll need a schema and an idea of how you are going to get information into and out of the database. Much of actual program involves such known things.
But what if you are doing something no one has done before? Software engineering simply doesn't have anything to say. Computer science involves developing means for information processing, much like X engineering is limited by whatever X is (i.e, "mechanical" engineering). But that computer science deals with "information" doesn't really limit it at all.
The only limits that can be said about information processing are either (1) so fundamental to be of no use in all but the most theoretical work, or (2) so abstract that they can never be translated into things we need.
For an example of the first, we have Turing machines. They place theoretical limits on computer science. But rarely do you see someone say, "I would do that, but it is an impossible task for a Turing machine."
For an example of the second, we have software development models. These are usually prescriptive in that they say you should write lots of documentation and form a byzantine design document before you even start thinking about code. Regardless of their relative merits, you cannot use these models to gleen any useful information. For example, the waterfall model will tell me that I should do this, and I should do that, but it will not tell me what I want to know, which is how long the project will take.
That being said, I think most attempts at analyzing a problem before solving it are doomed to failure. To determine feasability, you just have to do it. I recall several times when I would figure out a simple way to do something when analysis had previously determined, "This is impossible or impractical because..."
Computer science is about solving problems. Software engineering is trying to solve the problem of solving problems. But you can only abstract so much. In the end you have to solve the original problem. You can't just form some abstraction that lets you solve anything that could possibly come up.
No, really, I loved my job so much I retired early. Now, computers are fun again.
It means "the quality goes in before the name goes on".
Sheesh, evil *and* a jerk. -- Jade
From an accredited university What is Software Engineering
A troll is someone who posts stupid crap to lower the overall quality/intelligence level of the discussion, generally ruining everyone's fun and making people not even want to bother reading any more.
Example: in response to someone accidentally typing "way to much" instead of "way too much", saying "Way to much! You much like a pro!"
Flame-bait's goal is to get other people to get angry and reply. To "incite an online riot", as you say.
Example: going to a women's rights discussion group and saying "All Women who have abortions are murderers and those who die in clinic bombings DESERVE what they get"
There is of course a blurred line between the two. If someone is posting for no reason other than to be flamed, he is flamebait and a troll. Of course, if someone is posting something to provoke people, but only because he believes in what he is saying and is willing to back up what he says, moderators have no place giving it a "flamebait" rating- it is more likely that "offtopic" would be more suitable.
Generally, if a post does nothing but lower the average intelligence of the discussion, but offers little room for a response, it is Troll. If the same, but seems to beg response, it is Flamebait- it wasnt that the person said "Abortion doctors should die", it was that they said it in a women's rights board which made it flamebait.
the moderation "Flamebait" should be used sparingly. There really are very few flamebait posts, and those which are flamebait are made by Trolls anyway- you would be safe moderating all such posts as "Troll"
And finally: Don't thank people in advance you fucking cocksucker.
-- 'The' Lord and Master Bitman On High, Master Of All
What's that? Since when did 'social responsibility have anything to do with good engineering of any kind?
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.
Stupid job ads, weird spam, occasional insight at
While some educated folks seems to dislike natural talents and vice versa there are clearly room for both. The last 20 years has been a party to all people with natural programming talent since the sallary you'll make widelly exceeds what the engineering folks in other businesses gets. I do have some academic experiences but the equipment available and the things taught at the time fifteen years ago were far from 'bleeding edge'. However some understanding about algorithm mechanics and the mathematical backgrounds is very interesting but phew so theoretical. I quit the class after a year and I do call myself a 'programmer' and is proud of its labour status. :-)
Software engineers, if we define them as academic folks, do praise prediction and development processes. My experiences are that some of them do not consider development time as a valid design criteria. For them there are only one way to make the solution, the 'right' way. Often this means that they run out of budget or miss their time-to-market window.
Programmers on the other side, as I see myself, are often tied to a delivery time, a black box definition and some constraints in terms of design. A programmer can vary from 0 to 100 times in effeciency depedning on talent and circumstances. Given an algorithm, tools and a reasonable deadline a programmer will deliver. Any obscticle on the way is a challange and makes a thrill. A delivery is good fun!
A software engineer doesn't vary as much as a programmer in skills/talents and does often know how to work in teams better. Facing an obscticle may sometimes ripple down to massive re-analysis and re-designs to get it 'right'. A delivery is a scary thought, since most time have been spent analysing the problem and understanding the design, not coding, so ofcourse there will be bugs, but where??!!
A 'hacker' is a talent and a 'cracker' is a prank.
Software Engineering is to Engineering as Lightning Bug is to Lightning
He was talking about Orgasms.
Glonoinha the MebiByte Slayer
You can't engineer most software, for the same reason you can't engineer a book; it satisfies emotion, not logic. Most of the time, "success" or "failure" of software cannot even be defined! (see staggeringly successful, stupid and unreliable systems such as Micros~1 Windoze(tm)). Failure in engineering projects is usually, tragically, easy to define (see "Columbia").
It simply takes a different kind of duck to do software than it takes to do engineering. Have you ever met someone who can remember what they had for breakfast on July 23 1993, can remember the specs on a specific type of transistor, but can't come up with a efficient method for solving some seemingly novel problem? Thats an engineer. Ever met someone who, in a "eureka" moment, manages to re-frame a sticky problem so that it suddenly becomes solvable? And then turns out the code to do it in an afternoon, and it works first try? That might be a Programmer. Sometimes, you might even get both in the same package (you'd call him a Genius). But usually, people that are good at engineering, are very frustrated by programming.
I just hope to sometimes be called a Programmer.
-- -pjk Perry Kundert perry@kundert.ca http://kundert.2y.net
If you look at how "Engineering" is defined, it centers around developing a specification on how somthing is to be built, and ensuring what is being built is following that specification.
So it appears to be more managment of the "cheap labor" of the construction workers to make sure they don't kill someone, or waste an ungodly amount of money.
As far as programming goes, there is no cheap labor involved, and the detailed specification is the end product. So there isn't, and will probably never be anything that is analogus to an EE, ME, or IE. But that doesn't mean programming is any easier.
Software Engineering is a term that will be used to describe what used to be done in the USA. Like transistor radios, TVs, and Levi's, it flushing itself into the third world at an unprecedented rate.
For me it comes down to social responsibility. Engineers are the only profession that are not ultimately responsible to an individual but to society as a whole. Doctors and lawyers only look out for a particular client. If an engineer fails, the results are bad for society. The fact that we work with imperfect materials keeps us awake at night. Things like the Columbia make me physically ill because I empathize with every engineer involved in that project.
And from my, admittedly narrow, view of software engineering, I don't see that sense of social responsibility. I design oil refineries for a living, and to do so I use some high end engineering software packages to simulate new plant designs. Using software allows me to evaluate more options faster and to design to tighter tolerances. This is more efficient, and engineers and their clients love efficiency. But if there is an error in the software I use to design this plant, the software company will in no way take any responsibility. I know this going in, and because I have a lot of experience with what does work, I know how to spot a software result that doesn't. The ultimate responsibility lies with me. And until I see software engineers taking that kind of responsibility for their products, I really can't see considering them as engineers. I have yet to see any piece of critical software that doesn't have disclaimers on it.
Hey, I'm a professional, and like other professionals, I have a vested interest in maintaining the standards of my profession.
Laugh while you can, monkey boy!