Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming IT Technology

How Software Engineering Differs From Computer Science 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."
This discussion has been archived. No new comments can be posted.

How Software Engineering Differs From Computer Science

Comments Filter:
  • Perspective? (Score:4, Insightful)

    by dov_0 ( 1438253 ) on Saturday June 06, 2009 @02:10AM (#28230523)
    How about a rigorous, ever changing, ever intriguing discipline? It already is and will be more so.
  • by KnowThePath ( 964067 ) on Saturday June 06, 2009 @02:21AM (#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.
  • by Anonymous Coward on Saturday June 06, 2009 @02:35AM (#28230615)

    Humans are not maths.

  • by mad zambian ( 816201 ) on Saturday June 06, 2009 @02:36AM (#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.

  • by Idiot with a gun ( 1081749 ) on Saturday June 06, 2009 @02:42AM (#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.
  • by jbacon ( 1327727 ) <jcavanagh617@nOspAM.gmail.com> on Saturday June 06, 2009 @02:57AM (#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:Perspective? (Score:2, Insightful)

    by Anonymous Coward on Saturday June 06, 2009 @02:59AM (#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.

  • by bill_kress ( 99356 ) on Saturday June 06, 2009 @03:05AM (#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.

  • Easy (Score:1, Insightful)

    by Anonymous Coward on Saturday June 06, 2009 @03:13AM (#28230781)

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

  • by Anonymous Coward on Saturday June 06, 2009 @03:30AM (#28230845)

    You're obviously a coder, not a programmer

  • Re:Experience (Score:4, Insightful)

    by symbolset ( 646467 ) on Saturday June 06, 2009 @03:37AM (#28230861) Journal

    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.

  • by Chris Snook ( 872473 ) on Saturday June 06, 2009 @04:03AM (#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 (Score:3, Insightful)

    by petrus4 ( 213815 ) on Saturday June 06, 2009 @04:05AM (#28230949) Homepage Journal

    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.

  • Repost, sorry. (Score:2, Insightful)

    by symbolset ( 646467 ) on Saturday June 06, 2009 @04:17AM (#28230995) Journal

    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.

  • well, duh (Score:3, Insightful)

    by dirtyhippie ( 259852 ) on Saturday June 06, 2009 @04:23AM (#28231017) Homepage

    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.

  • by Bearhouse ( 1034238 ) on Saturday June 06, 2009 @04:24AM (#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 ;-)

  • by johannesg ( 664142 ) on Saturday June 06, 2009 @04:31AM (#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.

  • by tyrione ( 134248 ) on Saturday June 06, 2009 @04:31AM (#28231063) Homepage

    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 b

  • Not just software (Score:3, Insightful)

    by Darinbob ( 1142669 ) on Saturday June 06, 2009 @04:37AM (#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.
  • by ishobo ( 160209 ) on Saturday June 06, 2009 @04:53AM (#28231163)

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

  • Re:Perspective? (Score:5, Insightful)

    by ThePhilips ( 752041 ) on Saturday June 06, 2009 @04:53AM (#28231169) Homepage Journal

    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.

  • by Anonymous Coward on Saturday June 06, 2009 @05:06AM (#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.

  • by hutchike ( 837402 ) on Saturday June 06, 2009 @05:49AM (#28231365) Homepage Journal

    Software Engineering = fashion
    Computer Science = maths

    Simple. Nuff said.

  • by BiggerIsBetter ( 682164 ) on Saturday June 06, 2009 @05:57AM (#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.

  • by TheLink ( 130905 ) on Saturday June 06, 2009 @06:08AM (#28231423) Journal
    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.
  • by AlXtreme ( 223728 ) on Saturday June 06, 2009 @06:21AM (#28231463) Homepage Journal

    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:Experience (Score:3, Insightful)

    by CptPicard ( 680154 ) on Saturday June 06, 2009 @06:49AM (#28231549)

    The problem is that that was not a shortcut.. it was a humongously wrong statement that shows you probably do not understand the concept you're mentioning.

  • by petes_PoV ( 912422 ) on Saturday June 06, 2009 @08:27AM (#28231913)
    Whereas computer scientists go into research or teaching - to produce more computer scientists.
  • by nonregistered ( 639880 ) on Saturday June 06, 2009 @09:16AM (#28232177) Homepage
    As a degreed engineer with 30 years of work in computer hardware and software, I firmly believe there will be no such thing as a "Software Engineer" until such engineer has a "PE" after his/her name. That's "Professional Engineer" (wiki it); a responsible party who can be put in jail if the software kills someone. There's nothing like the threat of punishment to put rigor in your processes.
  • by russotto ( 537200 ) on Saturday June 06, 2009 @09:44AM (#28232367) Journal

    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.

    If you're going to insist on rigorous naming, you ought to be consistent about it. Programming != "the IT crowd". There's some overlap, but there's a lot more programmers not in "the IT crowd" and a lot more to be done than programming within the "IT crowd".

    Furthermore, I don't care how many bridges, buildings, or aircraft you can design, if you can't drive a steam locomotive (with attached train), you ain't no engineer.

  • by russotto ( 537200 ) on Saturday June 06, 2009 @10:50AM (#28232941) Journal

    Most undergraduate students don't have enough time to learn the basics of computer programming, never mind software design.

    If a student can't learn the basics of computer programming as part of a four-year program (whether CS, CE, or SE), perhaps programming isn't the field for him.

    In a perfect world, Computer Scientists (like myself, MS in CS) would be doing research and developing new advancements in CS.

    Unfortunately in this imperfect world, there's few such research positions available. But they aren't nonexistent. (as far as I'm concerned, you can have them, I prefer to get my hands dirty with code :-) )

    Plus, isn't an idea supposed to be a theory until proven to be a law? I mean does anyone really think it will continue indefinitely? I bet Moore didn't even think so. It seems we started calling it a law and it will continue until proven to be a theory.

    Different kind of law. Moore's law is more like Murphy's than Newton's.

  • Re:Perspective? (Score:3, Insightful)

    by jbengt ( 874751 ) on Saturday June 06, 2009 @11:12AM (#28233195)
    TFA is terribly confused. Although it was ostensibly about the obvious fact that software engineering is not the same thing as computer science, it instead spent a lot of time talking about whether or not software engineering is really an engineering discipline. Then it asks questions with false premises, like:

    Why can't software engineering have more rigorous results, like the other parts of computer science?

    (hint, engineering!=science, if you can't see the obvious, read your own article headline)

    When it says things like:

    No concept is precisely defined. . . . We believed that structured programming was the answer. Then we put faith in fourth-generation languages, then object-oriented methods, then extreme programming, and now maybe open source.

    then you know it is even more confused, using debates about improvements in languages, language paradigms, work/management methods, and licensing types to try to show that software engineering is not rigorous science. That is like comparing varieties of apples, oranges, bananas, and pears in order to make the point that plants are not safety-tested automobiles.

  • by ClosedSource ( 238333 ) on Saturday June 06, 2009 @11:25AM (#28233313)

    Nothing magically grants you "the ability to design large or complex software systems", no matter what degree or title you have.

    All this discussion about Computer Science vs. Software Engineering vs. Programming is really about ego and will not lead to any improvement in any discipline.

  • Re:Perspective? (Score:3, Insightful)

    by commodore64_love ( 1445365 ) on Saturday June 06, 2009 @11:28AM (#28233345) Journal

    Let's rewrite your words and the original article's words a little bit:

    [Electrical] Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. Writing [circuit card VHDL] is a creative process, arguably even an artistic one...... But maintainability crucially involves humans, and their ability to grasp the meaning and intention of [schematics].

    [Automotive] Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. [Designing steering wheels and consoles] is a creative process, arguably even an artistic one...... But maintainability crucially involves humans, and their ability to grasp the meaning and intention of [mechanical drawings].

    [Civil] Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. [Designing roads and bridges] is a creative process, arguably even an artistic one...... But maintainability crucially involves humans, and their ability to grasp the meaning and intention of [surveys].

    .
    I call bullshit. ALL engineering disciplines involve creativity, require humans to maintain the design, and an ability to preplan how customers will interact with the finished product. It sounds to me like this professor/programmer/whatever is trying to make excuses for why software is not as reliable as other engineered products.

  • Re:Experience (Score:5, Insightful)

    by scamper_22 ( 1073470 ) on Saturday June 06, 2009 @12:31PM (#28233971)

    I think the real issue is there is no 'routine' aspect to software.

    Most other domains of Engineering have a very defined field and set rules. There are also very standard way of doing things. Simulators have been built...
    I would argue that anytime some *new* device in another field of engineering is done, it suffers from the same 'flaws' as software. I can't speak for too many other fields, but I can speak for electrical engineering. Any new kind of hardware follows the same kind of iterative, simulate, debug... aspect as software. Fortunately, for hardware it needs to accomplish its set goal and people recognize the costs involved... and it somehow managed to escape the anyone can code mentality.

    Now software, we must understand is be definition new. ANY repetitive work is done by the tools (compiler, linker...). In Civil Engineering, you still need the civil engineer to oversee the building of the structure. To make sure the workers do things correctly... this is all very routine work. Often there are standard blue prints already done and the civil engineer just makes some small tweaks and then has to oversee the project. Just follow the damn process. In software, we are so fortunate, that our builders (compiler, linker...) work amazingly well. They never make a mistake and can repeat their work as often as possible.

    Once built, software can be deployed a million times over without fail. Not so for civil engineers who must pursue the same rigor each time a building is built.
    Heck in software, we like to make one deployment so flexible by these amazing things called 'options'. everything is a bloody option and configurable. Again, unlike many other forms of engineering where the regularity and standard process dictates how things are done.

    We must understand this key difference. Because of the nature of software, *some* people have made the mistake of trying to superimpose other disciplines onto software.
    There are those who would say that software is design and implementation.

    First you design it, like the civil engineer designs the building.
    Then you implement it, like the workers build the building.

    I cringe whenever I hear a similar analogy. Yes, there is some 'abstract' notion of design away from a specific language, but expressing that design in a particular language is still design.
    The civil engineer who uses autocad or whatever to design their building is expressing his design in that format.
    The software engineer is just expressing his design in C++/Java...
    THERE IS NO IMPLEMENTATION WORK IN SOFTWARE.
    Everything is design. Just high level design and low level design.

    Sadly, some people continue to try and draw parallels with factory or civil engineering work. They claim there is some design that can be done, and then a bunch of code monkeys (construction workers) assemble and build the software. It's so wrong on so many levels, I'll repeat it again. The compiler and linker assemble and build the software. Every code monkey is doing design.

    For sure, I think we will get *some* formalization of the process as certain practices become more standard. Our tools will most certainly become better and better (issue trackers, source control...). Yet at the end, the code still needs to be designed. There is no escaping the need for good software engineers.

    Just like there is no escaping the need for good civil engineers if you every try and do something out of the ordinary.

    I could write more about formal testing and the like, but I'll leave this point as is.

  • by Jaime2 ( 824950 ) on Saturday June 06, 2009 @02:26PM (#28234807)
    More specifically, an Engineer is someone who can claim that a system won't kill people and can legally transfer the responsibility for the lives of the users from the construction company to himself. What we don't have in the software industry is the accountability that forces Engineers to be rigorous. Sure, we software developers can claim that we use rigorous processes, but every time something doesn't work, we shrug it off and get to work on the fix. If a real Engineer screws up big just once, he loses his license and/or goes to jail.

    What makes licensed Professional Engineers so mad about the computer industry's flippant use of the word engineer is that it dilutes the title that they worked hard to obtain and that gives them a very unique position of responsibility in certain aspects of life. Don't think of an Engineer as someone who is good at any specific thing, think about them as a gatekeeper of the use of technology in public places.
  • Re:Perspective? (Score:3, Insightful)

    by Tony Hoyle ( 11698 ) <tmh@nodomain.org> on Saturday June 06, 2009 @05:41PM (#28236679) Homepage

    Science and Religion really don't interact at all. Science makes an attempt to explain the world as observed through our own eyes (or instruments). Religion offers an explanation and where that differs from observed reality, assumes reality is wrong!

    You can take the view that as we'll never know the truth about the universe that both are valid perspectives - but you can't say they're complementary in any way. Scientists don't need to 'work with religion' - they work with reality - and if reality coincides with religion they have no argument.. where it conflicts, there's no point in discussion, because neither side is going to change their opinion.

    Now it's true that lots of scientists are elitist jerks - mostly they're elitist jerks towards other scientists.. it's not an issue with religion, it's a problem with what happens when people spend a lot of their time in one discipline and have too much ego invested in it. Lots of programmers are elitist jerks too. I bet somewhere there's a group of elitist jerk balloonists too.

Remember to say hello to your bank teller.

Working...