Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Software Engineering Differs From Computer Science

Soulskill posted more than 5 years ago | from the read-comprehend-debug dept.

Programming 306

cconnell sends in a piece he wrote for Dr. Dobb's which "argues that software development will never be a fully formal, rigorous discipline, and the reason is that software engineering involves humans as central to the process." Quoting: "Software maintainability, for example, is the ability of people to understand, find, and repair defects in a software system. The maintainability of software may be influenced by some formal notions of computer science — perhaps the cyclomatic complexity of the software's control graph. But maintainability crucially involves humans, and their ability to grasp the meaning and intention of source code. The question of whether a particular software system is highly maintainable cannot be answered just by mechanically examining the software. The same is true for safety. Researchers have used some formal methods to learn about a software system's impact on people's health and property. But no discussion of software safety is complete without appeal to the human component of the system under examination."

cancel ×

306 comments

Sorry! There are no comments related to the filter you selected.

First! (0)

Anonymous Coward | more than 5 years ago | (#28230519)

Wouldn't it still be as much a science as say... human psychology?

Re:First! (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28230895)

Science != engineering.

Reading comprehension: you fail it.

Re:First! (1)

RDW (41497) | more than 5 years ago | (#28231415)

'Wouldn't it still be as much a science as say... human psychology?'

Pretty much:

'...and this area is maddeningly slippery. No concept is precisely defined. Results are qualified with "usually" or "in general". Today's research may, or may not, help tomorrow's work. New approaches often overturn earlier methods, with the new approaches burning brightly for a while and then falling out of fashion as their limitations emerge.'

Perspective? (3, Insightful)

dov_0 (1438253) | more than 5 years ago | (#28230523)

How about a rigorous, ever changing, ever intriguing discipline? It already is and will be more so.

Experience (1)

symbolset (646467) | more than 5 years ago | (#28230571)

You need more of it.

Re:Experience (1)

dov_0 (1438253) | more than 5 years ago | (#28230647)

You need more of it.

Haha. Probably...

Re:Experience (4, Insightful)

symbolset (646467) | more than 5 years ago | (#28230861)

Don't we all need more experience?

The basics are pretty simple. And by the basics, I mean where Niklaus Wirth [wikipedia.org] got his ideas for the mathematical basis [wikipedia.org] for algorithms, Alan Turing. [wikipedia.org]

Then we learn about functional programming from the guys who invented it: Kernighan and Ritchie [wikipedia.org] . Grok lex and yacc and we're halfway there. After we've written three or four languages we realize their purpose is to formalize our interaction with libraries of prewritten code. Along the way we learn about the importance of portable compilers and the interdependence of portable compilers and portable operating systems and libraries of prewritten code, and the importance of all of those to the persistence of data.

Then we study the evolution of C++ and figure out by ourselves why its inventor Bjarne Stroustroup [wikipedia.org] is a brilliant idiot. (Hint: it has to do with interface hiding).

We join the ACM and read and understand their Communications up until 1990 (anything after that is encumbered by patents). This takes a very long time.

And then we invent some stuff and every fool that just got his AOL account feels qualified to call us an idiot because we didn't do things the way he expected.

How about a rigorous, ever changing, ever intriguing discipline? It already is and will be more so.

It is. You were right.

Repost, sorry. (2, Insightful)

symbolset (646467) | more than 5 years ago | (#28230995)

There toward the end I meant to post this Zen summary:

After all that you begin to realize that the more you know, the more aware you are of the vast expanse of things you don't know. And then I arrive at what you said in 16 simple words, by a long discussion. I guess you're smarter than me.

Re:Experience (1)

siloko (1133863) | more than 5 years ago | (#28231107)

Me? I just started writing games on my Vic 20,

Re:Experience (5, Informative)

beelsebob (529313) | more than 5 years ago | (#28231207)

If you think K&R invented functional programming, you're sorely mistaken, Go look up people like Peter Landin and Haskell Curry. Secondly, if you think that the C language book has anything to do with Functional programming, you *badly* need to get an education with regard to what FP is.

Re:Experience (1)

solferino (100959) | more than 5 years ago | (#28231319)

Mod parent up. Exactly what I wanted to say. K&R as the founding text of functional programming is just a bizarre idea.

Re:Experience (1)

symbolset (646467) | more than 5 years ago | (#28231357)

You know sometimes to put some information into a format that fits in a slashdot post, you have to take some shortcuts - especially if the baby wants the keyboard.

I'm sorry if you think I've taken excessive liberties with the truth. That was not my intent.

Re:Experience (2, Informative)

smallfries (601545) | more than 5 years ago | (#28231385)

It's an interesting point, and because I can see a fair littering of good comments by you all though this discussion I'm intrigued - what did you mean?

K&R derived C from BCPL which was the non-hard-to-compile parts of CPL. The hard parts went on to become the basis of several functional languages.

Re:Perspective? (2, Insightful)

Anonymous Coward | more than 5 years ago | (#28230717)

Software Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be. Writing software is a creative process, arguably even an artistic one. Well understood rules can be followed, provably correct algorithms applied, formal design methods used, but it is still a human creative process, and as such, I suspect inherently non-rigorous.
Computer Science compared to Software Engineering?
Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.
Engineering aeronautics is all about building the damn aircraft.

Analogy? (2, Funny)

siloko (1133863) | more than 5 years ago | (#28231139)

Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.
Engineering aeronautics is all about building the damn aircraft.

I'm struggling to see how aeronautics and aircraft have anything to do with cars.

Re:Analogy? (2, Funny)

beelsebob (529313) | more than 5 years ago | (#28231215)

Look at the wings on any fast car, and you'll see.

Re:Perspective? (5, Insightful)

ThePhilips (752041) | more than 5 years ago | (#28231169)

Computer Science compared to Software Engineering?
Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.
Engineering aeronautics is all about building the damn aircraft.

That's pretty much how I think myself.

Engineering would stop being engineering if it becomes a science.

Engineering is in deep real world, with human nature and business requirements intervening all the time. Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula. They are both trying to understand a problem - but from different angles. So different - or better say orthogonal - that they are guaranteed to cross only rarely.

Writing software is a creative process, arguably even an artistic one.

Same with science. I'd say that in the respect there is not much difference.

The difference is as I try to put it above is that in engineering "it must work," while in science it doesn't even have to compile. It only has to work in some ideal world with unlimited resources and non-existent foreign factors.

Re:Perspective? (1)

pallmall1 (882819) | more than 5 years ago | (#28231179)

Software Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be.

After watching the ISO debacle approving microsoft's OOXML, I must agree with you.

You're not Engineers. Get over it. (0, Flamebait)

Anonymous Coward | more than 5 years ago | (#28230557)

Look, there is nothing wrong with being a programmer. Just as a good tech gets pissed off when he sees a 'nail technician', real engineers laugh at the IT crowd.

No engineering degree = no engineer.

Re:You're not Engineers. Get over it. (1)

calmofthestorm (1344385) | more than 5 years ago | (#28230567)

The usage varies by country. In America an engineer or technician refers to a profession, in some parts of Europe it refers to a degree.

But then I'm not an engineer by any definition.

Re:You're not Engineers. Get over it. (1)

ruckc (111190) | more than 5 years ago | (#28230911)

Hmm, I always thought you needed to be a state certified engineer to call yourself an engineer. If not, well then damn, i'm labeling myself a solve-interesting-IT-problems-that-no-one-else-can-engineer.

Re:You're not Engineers. Get over it. (1)

calmofthestorm (1344385) | more than 5 years ago | (#28230927)

Quite possible, but I know in some countries you are granted an Engineer's Degree instead of a Ph. D. for analogous work in an engineering discipline.

Then again, my US school (Caltech) mentions that some date is the "last day to defend your dissertation [for this year] for the degress of Doctor of Science and Engineer". So maybe it's here as well, I don't actually know.

Semantics, semantics

Re:You're not Engineers. Get over it. (1)

ishobo (160209) | more than 5 years ago | (#28231083)

Professional Engineer (PE) needs a license. The rules vary from state to state, with all requiring you to pass the NCEES Principles and Practice Exam for your chosen field.

http://www.ncees.org/exams/professional [ncees.org]

Re:You're not Engineers. Got train? (0)

Anonymous Coward | more than 5 years ago | (#28230607)

You need a choo choo train for that

Before we get all sweaty about terms (5, Funny)

symbolset (646467) | more than 5 years ago | (#28230631)

If you're an X Certified Y Engineer, you're a technician.

If you can be counted on to design a system that reliably works without killing people, you're an engineer.

If you can observe phenomena, reliably document previously unobserved phenomena, and from that produce useful but not mathematically precise practices or products you're a scientist.

If you can gather observed facts into a sheaf of postulates and a system of symbols that can predict unobserved phenomena, you're a mathematician.

If you can't do any of the above, you can always check bags at LAX for $150K a year.

If you can't get bags from the trunk to the belt, you might consider a position in middle management.

Re:Before we get all sweaty about terms (0)

Anonymous Coward | more than 5 years ago | (#28230801)

#1 in your list is NOT a technician, it's an engineer: that's actually quite an insult to engineers. engineer is a protected title in many states and some parts of the rest of the world and it's extremely frustrating to hear people refer to themselves as (software) engineers when in fact they have no professional qualification whatsoever.

Re:Before we get all sweaty about terms (1)

symbolset (646467) | more than 5 years ago | (#28230881)

Y'know, since I'm an X certified Y engineer I'm qualified to tell you that you're full of stuff. Not once in the field has a question been multiple choice.

The word engineer is well abused these days, and perhaps fairly so. Michelangelo was an engineer, and he didn't have any certs at all.

Re:Before we get all sweaty about terms (0)

Anonymous Coward | more than 5 years ago | (#28230991)

So I failed to see your joke: no sweat. I rise so easily to the bait on the misuse of the word :) I care very deeply about engineering and software and the two live happily side-by-side in my mind: we need to embrace the shared ground and understand the differences.

Re:Before we get all sweaty about terms (0)

Anonymous Coward | more than 5 years ago | (#28231217)

So I got all sweaty and rose to the bait, more fool me :) I am passionate about both engineering and software and they both live happily side-by-side in my mind: we can write better software if we embrace the common ground and properly understand the differences. True about Michelangelo: being too dogmatic about engineering isn't too useful...

Re:Before we get all sweaty about terms (2, Informative)

torako (532270) | more than 5 years ago | (#28231133)

...

If you can observe phenomena, reliably document previously unobserved phenomena, and from that produce useful but not mathematically precise practices or products you're a scientist.

If you can gather observed facts into a sheaf of postulates and a system of symbols that can predict unobserved phenomena, you're a mathematician....

Both describe a (natural) scientist. Mathematicians do entirely different things (they don't work with observed facts, they don't make postulates based on said facts, they definitely don't predict unobserved phenomena. That's all what science is for).

Re:Before we get all sweaty about terms (1)

TheLink (130905) | more than 5 years ago | (#28231269)

It's not that hard to design a system that doesn't kill people. I can't recall the last time my DHCP server killed someone, even though I've killed it so many times.

In fact I'd say it's hard to design an autonomous system that can keep killing people despite everyone else trying to stop it.

Y'know like one of those killer robots from the future.

Re:You're not Engineers. Get over it. (1)

realnrh (1298639) | more than 5 years ago | (#28230655)

So how about a degree that says "Master of Science in Engineering" for Computer Science? Does that count as an engineering degree?

Re:You're not Engineers. Get over it. (1)

tempest69 (572798) | more than 5 years ago | (#28230775)

So how about a degree that says "Master of Science in Engineering" for Computer Science? Does that count as an engineering degree?

Nope... nice degree, but the degree must say engineering too..
and Engineers still dont consider software engineering to be engineering.
And this from someone who nearly has that exact plaque on my wall.
Storm

Is software "engineering" really engineering? (4, Insightful)

KnowThePath (964067) | more than 5 years ago | (#28230577)

Going by the wikipedia definition [wikipedia.org] decisions made in typical software development cycles don't seem to rely on a justification based mathematical or physical analysis. Admittedly I might be generalising, but is it more of a soft-skill then? ie something that you acquire on your own rather than something that can be formally taught or imparted as training? Makes you wince when you see all those job adverts asking for programmers to work in their "engineering departments"... Disc: I'm a coder myself, working in a structural engineering environment, so watching people design buildings around me feels more like "real" engineering... Go on, mod me down now.

Re:Is software "engineering" really engineering? (2, Informative)

Anonymous Coward | more than 5 years ago | (#28230583)

You'd be surprised how little "real" engineering involves "mathematical or physical analysis" sometimes. Most of the time it's more a matter of "do what we did that worked last time". Those people designing buildings are using a lot more intuition and estimation than you realize.

Re:Is software "engineering" really engineering? (4, Interesting)

KnowThePath (964067) | more than 5 years ago | (#28230645)

I'm not sure if I want to reply to AC's, but I forgot to mention I'm a structural engineer myself by education... Most structures of respectable size fall back on Finite Element Analysis to gauge the response to a variety of loads. [The estimation of loads is a research topic in itself, where the factors of safety comes from a rigorous stochastic-based reliability analysis]. Once analysis has been performed, design is a bit of intuition, but certainly not estimation - it's more of heuristics... so you say, "this worked last time, let me try this option and analyse if it'll work this time too."

Re:Is software "engineering" really engineering? (4, Insightful)

johannesg (664142) | more than 5 years ago | (#28231057)

I'm not sure if I want to reply to AC's, but I forgot to mention I'm a structural engineer myself by education... Most structures of respectable size fall back on Finite Element Analysis to gauge the response to a variety of loads. [The estimation of loads is a research topic in itself, where the factors of safety comes from a rigorous stochastic-based reliability analysis].

Once analysis has been performed, design is a bit of intuition, but certainly not estimation - it's more of heuristics... so you say, "this worked last time, let me try this option and analyse if it'll work this time too."

So... A "real" engineer uses heuristics, common sense, estimation, and best of all, a complete unreliable piece of _software_ that was written by a programmer (who we just established can never be an engineer since they cannot be rigorous) to rigorously analyse his work? Looks to me like you are building your bridge on rather shaky grounds there, if you'll forgive the metaphore...

In the meantime, I found myself wondering how maintenance works for real structures. Apparently you _can_ rule out the human factor there completely, making "real" engineering thereby far more rigorous? Don't forget that "maintenance" means something very different for software than it does for real structures: you don't have to paint your software once every two years... What we call maintenance really is "changing the structure that is already there to become something else". I'd like to see someone add a lane or two to an existing bridge without involving humans at some point as a fundamental factor.

Re:Is software "engineering" really engineering? (2, Interesting)

TheLink (130905) | more than 5 years ago | (#28231315)

> "complete unreliable piece of _software_"

I doubt real engineers would use a completely unreliable piece of software.

Real engineers are practical enough to use software works well enough. They're not mathematicians who keep looking for complete proofs, or 100% - they are well aware of the real world.

And in the real world, it will be exceedingly unlikely that the finite element analysis software will work fine for lots of different cases, but fail dangerously for your case even though it is not really very different to other common cases.

If the case is something really new and "far out", I bet a proper engineer would do more checks and perhaps add higher safety margins.

The other thing is, an experienced engineer will often know whether something is dangerous. It's just like you looking at a branch and guessing whether it will hold your weight or not. If a branch is way too weak it's easy to guess that.

Similarly if the software gives a result that's ridiculous an experienced engineer should notice it.

So the software has to give a result that's not ridiculous, but still dangerous despite the margins of errors etc.

It's more likely that the contractor botches up the job (or cheats) and doesn't build according to the required quality and spec - e.g. use more sand in the concrete to save cost, use less concrete, etc.

Re:Is software "engineering" really engineering? (3, Interesting)

johannesg (664142) | more than 5 years ago | (#28231459)

"completely unreliable piece of _software_"

I doubt real engineers would use a completely unreliable piece of software.

The point of this article was that software engineers are not real engineers because they lack rigorous frameworks and rely too much on human factors. Seen from that point of view, you really only have two classes of software: those that are rigorously engineered to be reliable (and the article already claimed those don't exist), and those that are not. The last group must therefore comprise all software that's out there.

Real engineers are practical enough to use software works well enough. They're not mathematicians who keep looking for complete proofs, or 100% - they are well aware of the real world.

Fine, no problems with that. But "real engineers" should then also accept software engineers as real engineers. Software engineers are also practical enough to make software that works well enough - even though software engineers are not mathematicians who keep looking for complete proofs.

And in the real world, it will be exceedingly unlikely that the finite element analysis software will work fine for lots of different cases, but fail dangerously for your case even though it is not really very different to other common cases.

"We tried walking across it a few times and it stayed up, so it is probably fine" - Yeah, that sounds pretty rigorous to me...

If the case is something really new and "far out", I bet a proper engineer would do more checks and perhaps add higher safety margins.

Again, where is that rigorousness of which the article speaks? What you are proposing is just a matter of intuition, without any grounding mathematical framework.

The other thing is, an experienced engineer will often know whether something is dangerous. It's just like you looking at a branch and guessing whether it will hold your weight or not. If a branch is way too weak it's easy to guess that.

And an experienced software engineer won't know?

Similarly if the software gives a result that's ridiculous an experienced engineer should notice it.

And an experienced software engineer won't notice?

It's more likely that the contractor botches up the job (or cheats) and doesn't build according to the required quality and spec - e.g. use more sand in the concrete to save cost, use less concrete, etc.

...and we're back to human factors. Thank you for disproving the article entirely on your own.

Re:Is software "engineering" really engineering? (0)

Anonymous Coward | more than 5 years ago | (#28231087)

That's great, finite element analysis. Whoo. Believe me, I know that structural engineering is a relatively mathematically-intensive field of engineering. And it sounds like you're pretty proud of yourself for being able to divide up physical objects into slightly smaller pieces and simulate their properties, with software. But you think that's what makes you an engineer?

Because, when I think of "mathematical or physical analysis", I thought you might be talking about simulating structures from the atomic level, at least. As a software engineer, I have to account for the effects of cosmic rays when designing systems. Do you?

In order to do a thorough "engineering" job, I have to understand software in terms of electrons (or perhaps photons), with all their inherent limitations.

In addition to hardware, a typical software program is built upon three to five separate layers of abstraction. None of those add any performance benefits. They don't usually make the software more reliable or easier to debug. They just exist to make the software *possible* to build in an economically justifiable timeframe. I have to understand the benefits and limitations of up to a dozen alternatives at each layer, how they interact with each other and with external systems.

One or more of those layers may very well be a black box that I just have to trust works as the supplier claims, for both legal and practical reasons.

Furthermore, the software equivalent of the analysis you describe is usually a complete waste of time for a software engineer. Though it does occur, there's usually little reason to use mathematical analysis and software to simulate software. It's faster, cheaper and easier just to write the software, analyze it directly, and modify the parts that don't perform as intended.

So, with software being a non-physical abstraction that can be infinitely modified at very little cost, it should be obvious that the concept of "engineering" software may be somewhat different from that of "engineering" physical materials that haven't significantly changed in over fifty years.

Personally, I feel that software engineering is more difficult than most. But to each his own.

Re:Is software "engineering" really engineering? (1)

pallmall1 (882819) | more than 5 years ago | (#28231237)

As a software engineer, I have to account for the effects of cosmic rays when designing systems.

Ah. So that's how Steve Jobs projects his reality distortion field!

Re:Is software "engineering" really engineering? (1)

highways (1382025) | more than 5 years ago | (#28230613)

From Wikipedia:

"Engineering is the discipline and profession of applying technical, scientific and mathematical knowledge in order to use natural laws and physical resources to help design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective."

When was the last time you saw your structural engineers do their work from first principles taught at uni, as opposed to spreadsheet design or computer simulation?

The next question is, why should they?

I am a "software engineer" by profession, but my basic training is electronics engineering.

Without formal rigour, is software engineering a trade/vocation or a profession? My supervising senior engineer does a lot less maths and formal design than I do (which is mostly for sensor processing, which requires it), yet he solves most software implementation problems more efficiently and cleanly than I do. Does that make him any less of an engineer than me? I think not.

Sometimes I think "software engineer" is a bit of a catch-all title given by HR to those that are required to write software as part of their jobs (and is the main tangible output of their job), when in reality the design that they do could be any number of fields, software or otherwise.

Re:Is software "engineering" really engineering? (1)

TapeCutter (624760) | more than 5 years ago | (#28230833)

IAACS but my career has been in software development. Knuth captures your sentiement in the title of his legendary computer science text - "The art of computer programming".

Re:Is software "engineering" really engineering? (0)

Anonymous Coward | more than 5 years ago | (#28231075)

Quite so. Creating good software is an art as well as a science. All the engineering training in the world won't take you through the complexity to find the underlying simplicity. I'm suspect it's a sampling artifact, but all the self-identified "engineers" I have encountered have been worse at both design and implementation than the self-trained programmers I have known.

Formal definition of a software engineer (4, Informative)

OutputLogic (1566511) | more than 5 years ago | (#28230637)

Here is a formal definition of a Computer Software Engineer occupation, according to the US Department Of Labor [onetcenter.org] :
"Research, design, develop, and test operating systems-level software, compilers, and network distribution software for medical, industrial, military, communications, aerospace, business, scientific, and general computing applications. Set operational specifications and formulate and analyze software requirements. Apply principles and techniques of computer science, engineering, and mathematical analysis."

OutputLogic [outputlogic.com]

Re:Is software "engineering" really engineering? (5, Insightful)

Idiot with a gun (1081749) | more than 5 years ago | (#28230653)

In this case, "Physical analysis" would be running tests, deployment, crash analysis, etc. If we're comparing software engineering to "real" engineering, I feel it would be disingenuous to knock down software engineering because it works with code instead of physical items. The complexity is still there.

For me, what delineates "engineer" is much better defined in my mind by "engineering type." While a software engineers, civil engineers, and mathematicians may vary quite a bit in average disposition, they are more similar than dissimilar compared to the rest of the population. I genuinely believe that there is a major difference between the engineering mind (or in my case, CS), and everyone else. Similar to how painters, composers, and photographers all may vary in general, yet they're more similar to each other than the rest of the population.

Re:Is software "engineering" really engineering? (2, Insightful)

tyrione (134248) | more than 5 years ago | (#28231063)

Sorry, but Software Engineering houses most of its complexity in the actual complexity of the chosen language and Art of Design that has nothing to do with Traditional Engineering. I'll put it this way: Becoming proficient in C/C++/ObjC/Java is a matter of exposure to the language and various APIs with well-tested design patterns others have tested and shown to be useful, on a domain specific problem set.

Learning these languages is not remotely the same as learning Heat Transfer, Non-linear Dynamics, Quantum Mechanics, Fluid Dynamics, Machine Design, Fatigue analysis, etc.

In fact, 99.9% of all Software Engineers never touch actual traditional Engineering domain sets and thus require degrees in those fields to be able to apply their Programming Language, Frameworks/Libraries and more necessary to model, test and produce an Engineering Product for say Ballistic Missiles, Hydroelectric Power Systems, Nuclear Reactors, so on and so forth.

There is a reason you don't get looked at for a traditional Engineering position with a Software Engineering degree on your resume, versus having a traditional Engineering degree with a programming background.

How much of the commercial/open source software for consumers or enterprise clients requires the software to actually require factors of safety standards set by ABET/ASME/ASCE, etc., to actually adhere to Electromagnetic Theory, actual Mechanics and expect to be highly precise so as to be useful in modeling the Boeing 787 for FAA certification before its even run a test flight?

There is a huge difference between an actual true Engineering Discipline and Computer Science. There is a reason Bill Joy wants Computer Science to one day be on par with Mechanical Engineering. You don't see 50 differing versions of basic Calculus. You see 50 different programming languages with various pros/cons to justify their existence. This isn't acceptable in Engineering Fields that use applied Physics to make products which must guarantee Human Safety as a premium.

The biggest draws for clever programmers is the Web and Smartphones. You're not going to see Differential Equations [ODE/PDE] and Vector Analysis on their backgrounds unless they've switched careers from traditional Engineering to Programming--the money being the biggest lure.

Web Development ten years ago was mocked by traditional Software Engineers as not programming but writing scripts. How ironic that today the bulk of all "software engineers" are writing dynamic web sites/web services from the consumer to the enterprise and are fighting over getting their applications the most sales via smartphones. Cash talks bs walks in the world of the Internet. Traditional Engineering isn't a product of the Internet whereas today's drive for a lot of future chip design is to make sure the hungry mass consumers have those advanced features to see their precious content streamed to them in HD from their homes, to their phones all to keep them entertained and brain dead.

Traditional Engineering benefits from all of this progress but it's not driving these any more than email drove people to use Computers who normally would just write letter or call their friends back when a land line was the solution for all. You won't see blogs with tens of thousands of comments on a new advancement in Wind/Solar Technology specifics. You see 10,000 bemoaning posts tangentially spiraling into oblivion about how politically this or that new advancement may or may not ever be implemented and how this or that corporation blocks said advances to keep old technology in charge.

Software Engineering has evolved into keeping the masses glued to their computers where people can rant and rave by the millions. Its evolved into applying game physics to entertain kids as they continue to evolve into obese young adults incapable of being physically active. Its evolved into allowing traditionally inept large clusters of people from being more than a servant into being capable of driving a BMW, a Decati, a Porsche but still being no cooler than if they never had one. It's evolved into creating a culture of physically inept clods who have a short term skill set the ability to make far more money than ever possible in a traditional engineering discipline, never ever having to be required to have the broad and deep knowledge a traditional engineering discipline requires.

A similar comparison would be Rap with Sampling and how a bunch of obnoxiously untalented brats/thugs have made bling bling by the millions with only the rarest having the talent to even play an actual instrument.

Too much? Okay, okay. Some rhymes and jingles are catchy. Those folks in the past were big doing commercials back in the day. They are the reason why guys like John Mayer seem amazing because he can play a guitar somewhat [That should piss off a lot of people who'll claim he's on par with Clapton], can actually carry a note somewhat and carry the old torch of being a geeky musician who bangs famous attractive women one after the other all because they sell millions of copies of boring ass songs that seems to put women in a state of la la land.

I've gone off topic big time, but gawd if I have to read another claim that Software Engineering and Traditional Engineering only differ on semantics I'm gonna f'n throw up. That's like claiming that Steve Vai, Joe Satriani, Uli Jon Roth, to name three should ever be mentioned on level footing with a John Mayer, the Edge or say Lenny Kravitz as guitarists. Anyone with half a brain knows this to be utter cocka, but I bet these people claiming so haven't a clue who are the gods of their chosen instrument and who are nothing but Pop Media crap.Then again, 3 bar chords sold hundreds of millions in the 90s for various burn out bands from Seattle.

Re:Is software "engineering" really engineering? (2, Informative)

Anonymous Coward | more than 5 years ago | (#28231349)

"But Software Engineering houses most of its complexity in the actual complexity of the chosen language"

That's probably the reason why all my SE courses featured no code samples.

You really need to look up the difference between programming and software engineering before you throw up again.

Re:Is software "engineering" really engineering? (4, Interesting)

dov_0 (1438253) | more than 5 years ago | (#28230691)

Soft skill? Depends how well it's done. Lets use car repairs as an example. There are many times I've known or heard tell of where well trained city mechanics throw up their hands in defeat before the car is taken to either a 'mate who knows something about cars' or a 'bush mechanic' and fixed in 15 minutes. Ie. Sometimes the ability to observe, sort information well and problem solve is worth a lot more than a piece of paper with 'engineer' written on it.

Another example. I run a computer repair business with a 'no fix, no fee' policy. Even though I've never had a single day of formal training in the field, I have never, ever had to bring that policy into action. Meanwhile it's surprising how often my mates who have done IT or computer science ask me for help on something because they just don't know how to THINK.

Re:Is software "engineering" really engineering? (3, Insightful)

Bearhouse (1034238) | more than 5 years ago | (#28231021)

Meanwhile it's surprising how often my mates who have done IT or computer science ask me for help on something because they just don't know how to THINK.

Interesting post - I believe there are different kinds of thinking. I've had the benefit of learning how to fix cars by tinkering with them alongside my father since I was 10, and also a decent post-grad level education. I'm pretty good at fixing things, both cars and complex systems. I'm not special - there are plenty of people like me, including you, it would appear.

OK, some missed out on the practical stuff, and have thus never developed this 'practical' side. This does not make them incapable of thought IMHO.
For example, my wife is a lawyer - I'm amazed at her ability to spend hours 'thinking' about a complex case and then having that 'Eureka' moment when she finds the angle that she'll use for constructing a defense or attack. She's not worried about not knowing how to fix her PC or her car - she has a husband for that ;-)

Re:Is software "engineering" really engineering? (2)

physburn (1095481) | more than 5 years ago | (#28230723)

How much of software writing is software engineering. To deserve the name engineering take a problem that has to deeply analysised calculating a method of solution, programming is sometimes like that. But often i find i can start programming the solution straight away with just a bit of thinking about the class/object structure of the eventual program. When its like that is more like authoring a book, then engineering a machine.

Re:Is software "engineering" really engineering? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28230845)

You're obviously a coder, not a programmer

Re:Is software "engineering" really engineering? (1)

tibman (623933) | more than 5 years ago | (#28230921)

I'm being honest here, what's the difference?

Re:Is software "engineering" really engineering? (0)

Anonymous Coward | more than 5 years ago | (#28230941)

People who are good in the field can arrive at a well designed solution iteratively. Because you can't doesn't mean he can't. That's where great programmers/coders/developers/engineers and you differ.

Re:Is software "engineering" really engineering? (1)

crispytwo (1144275) | more than 5 years ago | (#28230729)

After working with engineers from other disciplines that create software, one begins to realize how different it is for those of us who create software for a living, especially stuff that a human can use. Engineers from other disciplines tend (and I'm generalizing) to be more derivative, when creating software.

Good software engineers, programmers, hackers, or whatever you want to call us think about problems differently. When we do our best work, it is because we see a problem that is new to us, and we see a solution or a potential solution. The result is software that the artistic, creative poets put together to function in a way that solves a problem. Sometimes it's elegant; other times it's horrendous. I'm sure you can think of many examples of each. But every time, it is something personal.

I agree that the idea of controlling development in some formulaic way is next to ludicrous. All you can really hope for is that the development is contained enough from getting unmanageable. Scope-creep, enhancements, limitations and their respective removals, all play havoc with rigour. I think you can easily see when software is getting to the unmanageable level; that's when you throw out and recreate. I've heard the cursing of other developers for decades and yet, no one escapes those curses. And it can go both ways... eg. Bob: Why TF did Joe do X?... and often enough... Joe: What TF was Bob thinking? X is now really broken!

Software is Art as much as it is anything else.

Re:Is software "engineering" really engineering? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28230977)

Architecture (at least when done PROPERLY) is a bit like that. It combines an artistic aesthetic along with a rigorous utilitarian ideal.

Pure utilitarianism in architecture wont win any awards, but gets the job done. (Example-- concrete houses.)

Likewise, pure art structures tend to have serious functionality issues. (Bad use of floor space, leaky roofs, plumbing problems, poor airflow from poor window location choice, etc.)

The pinnacle is reached when both of these come together harmoniously. Considering the utilities at work at the time, I find old 19th century "Victorian" houses to be exceptional at this. These houses were very beautiful to look at, incorporating many artistic, yet functional edifices, and were designed to give maximal floor space economy for the furnishings of the era, along with good natural ventilation through hall, room, and window placement. There are other such "Beauty meets function" designs found elsewhere as well, but the point still stands.

In the software world, you have the same basic warring principles;

The CLI application is utilitarian, effective, and no-nonsense.

They "eye-candy bloated UI" application may severely lack in true functionality, but boy it sure is "purdy."

The pinnacle comes when the balance is struck harmoniously between usefulness, utility, and ease of use (aesthetics).

If I were to put that label on a piece of buyware, I'd be tempted to cite NT4. It was lean, efficient, stable as a mountainside, and reasonably pain-free to use. It knew it was just an OS, and that the user merely wanted to use it to get work done. Granted, it's features are horribly dated by today's requirements. It's a bit like the previously mentioned Victorian houses.

[today's incarnations of windows remind me of an old victorian house that has had holes cut in the walls, and had 'amenities' forcibly installed in such copious and wild abandon that it ends up looking like PeeWee's playhouse instead. [youtube.com] (watch for full effect, and tell me you don't agree.)]

So, at least in my opinion, Software Engineering is quite a bit like Architectural engineering, except using virtual components and aesthetics, instead of physical ones.

Software Engineering is really Design (2, Insightful)

TheLink (130905) | more than 5 years ago | (#28231423)

Yep to me Software Engineering is more like Design.

The Architects design stuff, and the Builders build it.

The Programmers design stuff, and the Compilers build it.

The trouble is too many people don't get it and manage software projects the way they manage the Build phase of a civil engineering project. When they should be managing it the way they manage the Design phase.

The build phase of a civil engineering project can involve scores of workers and heavy machinery.
The build phase of a software engineering project involves the programmer typing "make all" and going to fetch a coffee.

The big problem:
Civil Engineering: build phase costs 10-100x design phase
Software Engineering: design phase costs > 1000x more build phase

And that's why Management ends up shipping the "plastic models/blueprints" as v1.0 since they compile and kinda work.

How software engineering differs from computer science is similar to the way civil/mechanical engineering differs from math.

Engineering does involve math, but a lot of times you don't really do a lot of math - something else does it for you :).
Same for software engineering, 90% of the time you aren't doing the "pure CS" stuff- sorting algorithms, info theory etc.

You're doing stuff like figuring out how to talk (and what to say) to some database or Active Directory, or whether the API for something is documented (correctly) or not. Or creating a brand new protocol that is not too inefficient and mere mortal programmers can use without screwing up.

Re:Is software "engineering" really engineering? (0)

Anonymous Coward | more than 5 years ago | (#28230765)

I absolutely agree: "real" engineering involves people and unpredictable/artistic/intuitive decision making processes as well (the difference is that designing code is almost ENTIRELY unpredictable). Perhaps other trained engineers in the software industry share my frustration with the general reluctance to apply ANY formal rigour to the process, using arguments like the one in this article as the general excuse?

Re:Is software "engineering" really engineering? (5, Interesting)

mcrbids (148650) | more than 5 years ago | (#28230803)

Going by the wikipedia definition, decisions made in typical software development cycles don't seem to rely on a justification based mathematical or physical analysis. Admittedly I might be generalising, but is it more of a soft-skill then?

That's just horsepucky.

The only reason it seems the way you mention is that software processing cycles are so ridiculously cheap compared to, say, 3" C-Channel girders. But just today, I was doing some engineering to develop a distributed, self-healing clustering file system. Specifically, I was doing performance analysis of different approach, doing a base unit of 1,000 simple file reads. That is most *definitely* a physical analysis - performance tuning always is. But do I care about each individual line? Not really. Do I do extensive analysis of each individual element? Not by a long shot, simply because the actual, real, overall cost of the software is so low.

We host highly complex, vertical-market database solutions. We have a pretty decent hardware cluster comprising some $25,000 in whitebox rackmount equipment. A nice half-rack of stuff. And another $10k or so for a failover DR scenario. But compared to the number of customers we service, and the size of my company, that's an insignificant investment, yet we are overbuilt at least 400%!

If 3" C-Channel cost $0.05 per linear foot, how much checking would you do beyond "good enough"?

Re:Is software "engineering" really engineering? (1)

KnowThePath (964067) | more than 5 years ago | (#28231361)

Whilst your argument is valid, cost is not the only governing factor when it comes to designing a structure - even if a Channel girder costs peanuts you still need to check your structure for safety and other parameters like say, environmental sustainability. (More material != Better design, irrespective of cost of structure).

I'm not really talking of the rigour of analysis or whether developing a file system is more "complex" than analysing/designing a 3 storied building. But the fact that decision making is supported using calculations that have been arrived at by experimentation, simulation or prototyping makes it a lot more empirical than programming.

Re:Is software "engineering" really engineering? (0)

Anonymous Coward | more than 5 years ago | (#28230981)

Go through a few law suits, specs become more rigid and standardized, maybe impose a few regulations, it'd be like any other engineering field. But then it won't be so "soft" - it would also become an oxymoron. Such is life.

Thank you, Captain Obvious! (2, Insightful)

Anonymous Coward | more than 5 years ago | (#28230615)

Humans are not maths.

Software Engineering is trying (5, Insightful)

mad zambian (816201) | more than 5 years ago | (#28230619)

.. to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be. Writing software is a creative process, arguably even an artistic one. Well understood rules can be followed, provably correct algorithms applied, formal design methods used, but it is still a human creative process, and as such, I suspect inherently non-rigorous.
Computer Science compared to Software Engineering?
Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.
Engineering aeronautics is all about building the damn aircraft.

Re:Software Engineering is trying (4, Insightful)

jbacon (1327727) | more than 5 years ago | (#28230707)

.. to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be. Writing software is a creative process, arguably even an artistic one. Well understood rules can be followed, provably correct algorithms applied, formal design methods used, but it is still a human creative process, and as such, I suspect inherently non-rigorous.
Computer Science compared to Software Engineering?
Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.
Engineering aeronautics is all about building the damn aircraft.

As a senior in a software engineering major, I tend to agree. While there are any number of methods, design tools/patterns, and whatnot to help me do my job, in the end it is my own ideas and styles that define the product. There's certainly an element of artistry to it - a small block of recursion that accomplishes something horribly complex is just... beautiful.

Another thing that contributes to its non-rigor is the domain knowledge requirement. I can't effectively build a system unless I understand (at least at a high level) how it works. Each industry has its own specialties and levels of difficulty, and you can't teach all of that in school, so they teach us how to think and learn instead. They give us ways of understanding the problems we need to solve, and that's really what we do - solve problems.

Re:Software Engineering is trying (2, Insightful)

AlXtreme (223728) | more than 5 years ago | (#28231463)

There's certainly an element of artistry to it - a small block of recursion that accomplishes something horribly complex is just... beautiful.

This reminds me of a fairly large OSS project where they were recursively doing SQL queries after certain actions to clean up. This worked, however they didn't take into account scalability.

The project I was using this for was about a factor 10 larger than usual and it became terribly slow. The database was being pummeled recursively with SQL queries and the whole thing came to a screeching halt.

The solution was simple: a single optimized SQL query that did exactly the same as that wonderfully complex recursive database-killing monstrosity. Yes, it's in the main branch now.

I'm all for artistry, but you have to know the limitations of your tools. Recursion is lovely but not if it hampers the project. Sometimes, in software engineering, beauty is knowing when not to use a beautiful tool.

Re:Software Engineering is trying (0, Troll)

Anonymous Coward | more than 5 years ago | (#28230767)

.. to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be. Writing software is a creative process, arguably even an artistic one. Well understood rules can be followed, provably correct algorithms applied, formal design methods used, but it is still a human creative process, and as such, I suspect inherently non-rigorous.
Computer Science compared to Software Engineering?
Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.
Engineering aeronautics is all about building the damn aircraft.

http://blog.soufun.com/blogweb/blog_manage/gratulate.aspx/userid=23799432 [soufun.com]
http://my.home.news.cn/blog/control/home.do [home.news.cn]
http://home.myspace.cn/index.cfm?fuseaction=user [myspace.cn]
http://my.51.com/webim/index.php [51.com]
http://10553007.blog.hexun.com/32715836_d.html [hexun.com]
http://sys2.blogcn.com/control/article.do?method=list [blogcn.com]
http://blog.chinamil.com.cn/user_index.asp [chinamil.com.cn]
http://blog.sanfo.com/user_index.asp [sanfo.com]
http://blog.titan24.com/blog.php?uid=414198 [titan24.com]
http://liulangqiuxie.blog.china.com/index.html [china.com]
http://blog.zjol.com.cn/spacecp.php?docp=me [zjol.com.cn]
http://www.blogbus.com/user/?blogid=4969180&mm=Post&page=&sortid= [blogbus.com]
http://www.mastv.cc/mastvblog/user_index.asp [mastv.cc]
http://blog.sina.com.cn/u/1192639293 [sina.com.cn]
http://blogs.albawaba.com/admin.php [albawaba.com]
http://blog.ycool.com/index.php [ycool.com]
http://home.q.yesky.com/space-4194762.html [yesky.com]
http://blogs.66law.cn/users/liulangqiuxie/ [66law.cn]
http://blog.aweb.com.cn/user/manage/articles.jsp [aweb.com.cn]

Re:Software Engineering is trying (1)

Tony-A (29931) | more than 5 years ago | (#28231275)

>.. to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be.
"Real Engineering" has something called "Strength of Materials". You can build a bridge out of wood or out of steel, but the designs will be different because engineers are aware that different materials have different properties and have some ability to quantify those differences. Designing a bridge so that it will "scale" would never be attempted in any real engineering discipline. However, engineers will make designs which are valid over some range.
Look real deep and I suspect that the creative processes are the more rigorous. "Just remove everything from the block of marble that isn't David" Just being different shouln't count as being creative.

Re:Software Engineering is trying (0)

Anonymous Coward | more than 5 years ago | (#28231475)

"Software engineering is trying to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be."

I'm certain that it is, the problem is not software developers, the problem is the complexity and cost of engineering. I'm sure given an infinite budget and the right people software development would become software engineering, the problem really is that:

1) No one wants to pay the true cost
2) Technology changes too fast and Ccrtain technologies go obsolete very quickly

The real problem with most software development ("engineerng") is time and budget, not the fact that it's impossible to engineer great software, just that the costs to do a good job as project complexity increases, increases enormously.

Chuck Connel does not understand Simon's work (3, Interesting)

tyrr (306852) | more than 5 years ago | (#28230659)

The author of the article should study a Noble prize-winning work "Administrative Behavior" [amazon.com] .

There is nothing secret about human cognition. The fact that software engineering relies on human resources and not on binary logic is in no way a limitation. Many modern algorithms rely on heavily on probability and work with uncertainty. Herbert A. Simon [wikipedia.org] built a solid framework for understanding human decision making process. This framework is just as solid as mathematical formulas behind computer science.

Re:Chuck Connel does not understand Simon's work (1)

oenone.ablaze (1133385) | more than 5 years ago | (#28231061)

I am going to agree with you for the most part—I feel that human-centricity doesn't necessarily imply a lack of rigor. Just because it requires dealing with the horribly complicated mess that humans are, one can still approach the problem at hand using rigorous, human-centric strategies. Learning how to work with human variation is not completely an intuitive affair, as there are a lot of frameworks, each with its own merits about how to understand humans and their behavior, and how to apply this understanding to disciplines like software engineering. Maybe this lacks "formality" in the sense that it's not formulaic in nature, but saying it's not rigorous is pejorative in a way that I'm not comfortable with.

On the other hand, saying that Simon's description of human decisionmaking is as "solid as mathematical formulas behind computer science" seems a bit silly to me—at best, it's just a good lens through which to explain some facet of human behavior, but even if Simon's work were a perfect, unassailable analysis of the human decisionmaking process (which it is not—how can we prove that neurologically speaking Simon is correct? We can prove that algorithms work all the way from the number theoretic level), understanding just decisionmaking wouldn't be enough for our purposes.

Software Development is actually an art (5, Insightful)

bill_kress (99356) | more than 5 years ago | (#28230747)

So, I'm sure, are a lot of things I don't recognize, like designing a sky-scraper or space shuttle.

Programming is an art, Anyone can follow instructions and follow an existing style or try to paint a realistic scene, but to come up with a skilled interpretation that really conveys a meaning takes a better painter. To bring together 20 painters, outline a collaboration and manage the production of some giant, detailed interpretation takes a master--at this point natural talent starts to mean more than training, and no level of training can improve someone without talent.

Anyone can write a small program. You can fit 20 generic programmers in a room and have them each write a small program. You might even be able to get them to join the programs somewhat-properly, but the whole thing will never go smoothly.

One or two really good programmers will probably out-produce 20 people that "know how to program".

How many amateur painters do you need to create something like the sistine chapel?

Just because most people can't see the art that allows large programs to work doesn't mean it's not there. In fact, most people can't tell any type of good art from bad without some training.

Like Architecture (2, Interesting)

msgmonkey (599753) | more than 5 years ago | (#28230915)

I've always compared software development to architecture in that you can give a specification for a building (size, floors, x rooms, etc) and you can get multiple designs that fit the specification but a great architects design will always stand out.

Sometimes I look at code and it just does n't "feel" right, sure it may work just fine but I may not like the design choices taken whilst sometimes I see code that is designed so well that the peices fit together seemlessly (not that often I'm affraid).

Re:Like Architecture (2, Insightful)

ishobo (160209) | more than 5 years ago | (#28231163)

Except architecture is a highly regulated and licensed profession, whereas any schmuck can write code.

Re:Like Architecture (1)

msgmonkey (599753) | more than 5 years ago | (#28231245)

Sure but that was n't my point, my point was multiple outcomes from the same specification.

Any schmuck writing code is like me getting a copy of AutoCad and drawing up a floor plan. Besides, I've seen many badly designed buildings so being regulated and licensed does n't guarentee good building, it just limits (but does n't eliminate) the possibility of buildings collapsing.

Re:Like Architecture (1)

ishobo (160209) | more than 5 years ago | (#28231437)

I realize that was not your main point.

When collaspes happen, if the architect or engineer (or firm) is responsible, there is a venue for a professional misconduct hearing, leading to the loss of license.

Re:Software Development is actually an art (1)

DNS-and-BIND (461968) | more than 5 years ago | (#28231033)

How can software engineers call themselves engineers? If an engineer designs a car and it crashes due to easily-avoidable defects, he goes to jail. If an "engineer" designs software and it crashes due to easily-avoidable defects, it's considered unavoidable.

Re:Software Development is actually an art (1)

julesh (229690) | more than 5 years ago | (#28231115)

If an engineer designs a car and it crashes due to easily-avoidable defects, he goes to jail.

[citation needed]

Re:Software Development is actually an art (1)

Enleth (947766) | more than 5 years ago | (#28231501)

No. If an engineer designs a car and it crashes due to easily-avoidable defects, his company is fined big bucks in court. If an engineer designs a program and it crashes due to easily-avoidable defects, his company tells the client "go read the EULA and fuck off, we're not responsible". So, the first engineer's company gives him the money, means and time required to avoid those defects. The first engineer's company doesn't bother, so the engineer doesn't find those defects, even if he'd like to, because he'd be fired for not meeting the deadline and wasting time on something that doesn't affect revenue.

Well, in fact, there were cases of car companies figuring out that paying a few families some change money would be cheaper than acutally fixing those easily avoidable defects, but that's another matter.

Software Development is a CRAFT (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28231219)

Let's face it. Most (if not all) programs we write are "made-to-measure" software, not mass production programs. You need craftsmen for that. Artists are usually only interested in the looks.

Software development is a skill that can only be trained. Trained to think like a hacker, to think like a newbie user, tothink like a client (client!=user), to know when to optimize and especially when NOT to optimize, trained to think in modules and their relations (I encountered far too many programmers who have difficulties with this). Trained to think in responsibilities. Trained to abstract. Trained to trust the unit tests. Trained to write them.

A good programmer is a craftsman. Someone who can build the wish of a client not exactly as the client has sketched it, but as a robust and working structure that does what the client wants.

An artist is someone who designs the famous "Z" chair and dares not sit on it.

A craftsman is someone who takes the idea of the "Z" chair and dimensions it right so it becomes a chair instead of an idea.

Re:Software Development is actually an art (3, Insightful)

BiggerIsBetter (682164) | more than 5 years ago | (#28231389)

I agree with the sentiment, but in a business context, I think that means we're doing it wrong.

Production software *should* be boring, and rigorous... and correct. Now, I know this has all been hashed out before, and it's one reason why we ended up with Agile methodologies, but very very very little of what we do needs to be clever, or innovative. Despite what we think, most of us aren't smart enough to build clever AND reliable software, so we end up crafting things rather than truly engineering them. Those of us who ARE smart enough probably aren't working on projects with enough budget to take the time to do so.

Easy (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28230781)

A computer science graduate creates the perfect program, then a software engineer goes and breaks it by making usable.

Old debate (2, Interesting)

jilles (20976) | more than 5 years ago | (#28230793)

I think more specifically, Software Engineering is an empirical discipline. All successful approaches in this field (scientific and practical) are about empirically measuring and adjusting what is going on rather than using mathematical models to analyze or predict things. This puts Software Engineering more in the realm of social sciences than that of mathematics. As a consequence, the current practice of old fashioned mathematicians that became computer scientist teaching software engineering in universities produces mediocre results since they typically lack the background for using empirical approaches. In other words they are effectively amateurs lacking both relevant experience in actually practicing software engineering (at least I observed this when studying CS) on large software systems and the necessary scientific background for studying software engineering in a empirical way.

Luckily this has been changing. Most of the better universities now have software engineering scientists that actually do have a clue when it comes to their topic. Also industrial practice is gradually progressing (although the number of cocky CS college dropouts ignoring 40 years of wisdom remains a problem). Methodologies like scrum and other agile approaches are solidly based on measuring what is going on and applying practices that have been demonstrated to actually work (as opposed to be predicted/assumed to work by some mathematician). Sadly most companies practicing these methodologies don't do so rigorously and only pay lip service to the whole notion. All the good software engineers I know combine excellent technical skills with good empirical and people skills. It's all about measuring what is going on rather than assuming or deducing from mathematical models. Good SEs use test suites, profilers and other means to find out how good/bad their code is.

So, maintainability is a function of how messy the software is (easy to measure with all sort of metrics), how well the code is covered with tests (easy to measure), number of bugs per kloc (easy to measure), and indeed experience of the people maintaining the software (not that difficult either). A typical mismanaged project will have some junior software engineer messing with the code until it works (sort of), lots of reported bugs, poor test coverage, and a manager who doesn't act on any of the things he/she should be measuring.

One of the interesting things about large open source projects is their Darwinist nature weeding out the bad ones. There's a lot to learn from how successful OSS projects operate. A lot of best practices find their origin in such projects. Things like version control, bug tracking, unit testing frameworks, etc are experimented with a lot in the OSS world. For example, Mozilla pioneered Bugzilla and was also quite early adopting continuous integration and automated tests. They developed a lot of technology and practices just to support knowing how they were doing. Most of that is now widely used across the industry. Ubuntu is doing similar things currently and projects like Eclipse maintain a very high pace of development with very consistent levels of quality in circumstances that most companies would be unable to handle.

Compare and contrast Comp Sci & Comp Eng (2, Funny)

play_in_traffic (946193) | more than 5 years ago | (#28230827)

One is not engineering. The other is not science.

Martin Fowlers - A New Methodology (0)

Anonymous Coward | more than 5 years ago | (#28230853)

Reminds me of Martin Fowlers "A New Methodology" paper.

http://martinfowler.com/articles/newMethodology.html

Engineering != Science (3, Interesting)

Anonymous Coward | more than 5 years ago | (#28230897)

Connell titles his article "Software Engineering != Computer Science." He later proposes Connell's Thesis, "Software engineering will never be a rigorous discipline with proven results, because it involves human activity."

I would suggest that the article's title reveals why software engineering doesn't have "proven results" in the sense that Connell means. It's not due to human activity. Rather: engineering != science. "Proven results" (i.e., a set of results logically derived as part of an axiomatic system) are more characteristic of a scientific field than an engineering discipline.

Engineering applies and relies on science, but is not science, per se. Mature engineering fields have standards and codes of practice, both science-based and empirically derived. When/if software engineering matures further, it is reasonable to expect such standards and codes to develop.

Re:Engineering != Science (0)

Anonymous Coward | more than 5 years ago | (#28231351)

You're right: standards and practices arise in other engineering disciplines through science and empirical knowledge (plus a bit of politics and a bit of legal action thrown in). I believe software engineering will one day mature, mainly through empiricism, but right now it's an angry teenager that's convinced no-one has ever felt like it does and that no-one could possibly understand.

Overlapping disciplines (1)

caywen (942955) | more than 5 years ago | (#28230903)

I think SE and CS are overlapping disciplines populated by people who tend to analyze the things that overlap and make (sometimes unnecessary) generalizations. Thus, it's natural that people in both disciplines make misguided attempts to define the relationship when in fact there is no stable relationship at all. It simply depends heavily on what you are doing. I could ask endless other similar questions, like: what's the difference between a musician and a composer? One can be the other, and one doesn't necessarily have to be the other, and one can be made better at one by learning about the other.

Re:Overlapping disciplines (0)

Anonymous Coward | more than 5 years ago | (#28231195)

I agree, at my place of study the difference between a bachelor of computer science and bachelor of software engineering is an extra year of maths and 'project' subjects.

The difference between Engineering and Development (2, Insightful)

Chris Snook (872473) | more than 5 years ago | (#28230943)

...is about a 1000x difference in cost per line of code. There's a lot of pure software engineering going on out there, but the products are relatively few (and usually heavily re-used) because the cost of being reasonably certain no one will die is really quite astronomical. Most people who call themselves software engineers with a straight face are really doing something in between, which is why we have entire libraries full of books describing methods that trade off varying degrees of safety for economy.

In one sense, software engineering can be considered a more formal discipline than other forms of engineering, because software engineering has studied in much greater depth the tradeoffs between formality and economy, since the spread between them is so much wider.

Elitist crap (2, Insightful)

petrus4 (213815) | more than 5 years ago | (#28230949)

The TFA, and any other such articles, amount to nothing other than navel
gazing. People who think they are a scientist/artist/whatever, thinking it
makes them more leet if they are able to exclude others.

The elitist attitude of contemporary science is something which I hold in
extremely deep contempt, to be blunt. Programming might not be considered a
pure science, if they want to try and claim that anything that
human beings do is completely free of emotion. Nothing does, so by that
definition, nothing is a pure science.

If you focus on the purely mechanistic/mathematical aspects of programming,
that can be considered science. If you focus on the emotion, or the level of
inspiration which sentience is considered a prerequisite for, it's an art.
Use whichever term for yourself that you want, or better yet, just be
you.

Remember Napoleon, people. The greatest Emperors crown themselves.

ognaa (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28230965)

well, duh (2, Insightful)

dirtyhippie (259852) | more than 5 years ago | (#28231017)

Seriously. CS asks questions of the form will X accomplish Y? Software Engineering asks questions of the form "what is the best way X to accomplish y"?

Nothing to see here, move along.

The reason why we are doing it manualy (0)

Anonymous Coward | more than 5 years ago | (#28231025)

... is that the Halting Problem and (verification of) Semanic Correctness of a program are formaly indecidable.

Not just software (2, Insightful)

Darinbob (1142669) | more than 5 years ago | (#28231089)

Some of these same old complaints exist with hardware too. It takes humans to detect the "bugs" in a circuit layout or to quantify how adaptable/modifiable it is (ie, maintainability). There's guesswork involved in figuring out how much to over-engineer something, finding the cheapest part that does what you need, crossing your fingers that a vendor doesn't discontinue a component. Hardware engineers may take a more rigorous approach than the typical software grunt, but it is still a human endeavor. Otherwise we couldn't have nearly so many board revisions and software wouldn't be used to mask over the hardware shortcomings.

The biggest problem with software is that it is easily malleable. We'd have far fewer bugs if it were treated like hardware that couldn't just be tweaked in the field if something is wrong; we'd be given more time to finish the designs and implementation, the testing would be built in and mandatory, nothing would be declared finished until several eyeballs looked it over and even then that would just be the initial prototype, and we'd have outside testing companies verify the solution for compliance with regulations. When software is malleable it's really hard to tell the bosses "sorry, we can't make that change" or "we can't ship this week because we added a bug fix and have to retest." Actually the same pressures exist in hardware (and other engineering discliples) it's just a lot more common with software.

Didn't carmack comment on this a few years back? (1)

UnknownSoldier (67820) | more than 5 years ago | (#28231127)

Can't seem to find the blog/article, but thought Carmack posted about being a game developer was akin to wearing different types of hats:
- architect (designing)
- engineering (building the program)
- scientist (diagnosing bugs)

I know this topic has been discussed back in 2004...
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=182392 [fogcreek.com]

Memory or IQ (0)

Anonymous Coward | more than 5 years ago | (#28231135)

The old argument of knowledge vs inteligence !

Knowledge = the ability to REMEMBER answers to standard questions to pass exams.

Inteligence = the ability to understand and solve problems and be able to find answers ( e.g. IQ)

The 2 have no direct link - I would rather a person has the latter than the former but that's rare with societys obsession with memory based qualifications

Multidisciplined (1)

sesteel (1570717) | more than 5 years ago | (#28231157)

I personally like the term software developer; though, my company formally calls me a software engineer. I am reading these comments about defining software engineering/development and it is obvious that it is difficult to quantify this discipline in terms of any other discipline. Software development is an inherently unique endeavor that requires I wide range of abilities and ways of thinking to solve difficult problems. Sometimes it requires rigor and a deep understanding of mathematical concepts. At other times it requires artistry and extreme creativity. And yet at other times it truly feels like working the line in a factory. It is beautiful in its exactness, many times revealing unexpected consequences. The latest US financial crisis has been contributed to unexpected consequences relating to software written in the 80's and 90's. At its core, however, is the goal of automation and thus freedom. We automate so we are free to perform other, hopefully, more desirable tasks. In order to accomplish this, software developers must learn about processes, machines, relationships between abstract concepts, communication, etc, etc, etc. Most importantly, however, we get to learn about people, learn about ourselves, and in the process learn about new things to automate

Fashion versus maths (2, Insightful)

hutchike (837402) | more than 5 years ago | (#28231365)

Software Engineering = fashion
Computer Science = maths

Simple. Nuff said.

The difference (1)

eznihm (552487) | more than 5 years ago | (#28231529)

Writing source code is craft, making source code executable is engineering.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>