Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Programming IT Technology

Define -- "Software Engineering" 118

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

Define -- "Software Engineering"

Comments Filter:
  • by the eric conspiracy ( 20178 ) on Friday January 31, 2003 @09:22PM (#5201082)
    Software engineering is about being able to perform software development with repeatable and predictable results.

    • Software engineering is about being able to perform software development with repeatable and predictable results.
      No it isn't since you never repeat writing the same software no more than an architect or engineer builds more than one of the exact same building, bridge, or whatever. Software applications aren't experiments to be repeated.
      • by Glonoinha ( 587375 ) on Friday January 31, 2003 @10:49PM (#5201478) Journal
        >Software applications aren't experiments to be repeated.

        No, we software engineers do not make the same mistake over and over. We make different mistakes each and every time.
        • As humorous as the remark is, it does have a certain insight.

          One of the things that struct me as setting engineering apart was it's unique concern for controlling failure.

          A program that can perform some intended fuction might just be the result of programing.

          But a program that can do this while failing gracefully in a controlled manner under certain understood conditions would be the result of software engineering.

      • by the eric conspiracy ( 20178 ) on Friday January 31, 2003 @11:39PM (#5201687)
        No it isn't since you never repeat writing the same software no more than an architect or engineer builds more than one of the exact same building

        Think like that and you will never be a software engineer. Every bridge, building and program is assembled from components with common structures. Bulidings have foundations, walls, support beams in the walls, windows, HVAC, etc. An architect can put these together, predict how they behave as a whole and estimate how much the assembly will cost time after time in a repeatable fashion, even though no two final buildings are the same. Software engineering is about the same thing - assembling a program from commonly used components and being able to predict the cost and operational characteristics of the final product even though no two such products are the same.

        • Think like that and you will never be a software engineer.
          I have been one for over a decade amd am doing quite well, thanks.
          Every bridge, building and program is assembled from components with common structures.
          No argument, but that's irrelevant to my post. My only issue was with the comparison to a scientific experiment that demands exact reproducibility: not just common components: exact to every last detail. Hence, the analogy is a poor one.
          • with the comparison to a scientific experiment that demands exact reproducibility

            Then your post was in response to something I did not write. Nowhere did I mention anything about a scientific experiment. Nor in fact do such experiments demand anything like exact reproducability. There is no such thing. All experimental results contain uncertainty and error due to variations in procedure, conditions and measurement.

        • Furthermore, I claim unless you are trading off things, you are not engineering.

          For example, you could use a commercial SQL package, or MySQL for the database; and you should weigh up and have a conscious reason for choosing one or the other, for that particular application.

          Clearly a commercial package will be more expensive, but may well be faster, but if you don't need the speed, then...

          Trading off is not a sufficient condition for engineering going on, you can be trading off without doing engineering, but it is a good sign.

        • If you are a top-notch software engineer, you will seldom build several things that are even similar. After the first or second such thing, you will figure out an abstraction that collapses the multiple designs into a single design with some sort of customization or parameterization. Then you are on to solve some other, completely different problem. If you are assembling known components into predictable patterns then you are probably pretty low on the IT food chain and ultimately replaceable.
      • Please read the Software Engineering Body of Knowledge [swebok.org] and stop calling yourself a Software Engineer.

    • First Axiom of software engineering:

      That which is repeatable and predictable is automatable.

      Go ahead a credit me for that one. I don't remember if I got it from anywhere. The whole point of writing software is to releive people of tasks that are tedious and error-prone for people. If there are predictable, repeatable steps to produce something, then a program can be written to perform those steps. The worst term I've heard for the act of actually writing software is "software construction." Ugh. Compilers and project tools construct or, as most of you are familiar with it, build software. Does an author construct a book? No, the printer does.

      What we do as developers is to design software. The design spec is the source code itself. We just have the privilege of having tools that construct from that design specification directly.

      Architects (real ones, not the ones in software) will actually work on many levels in a building, not just the highest levels. There's the lead architect that figures out what the main uses of the building will be, and comes up with a general vision of how that building will work. Then, if he's lucky and has other architects working for him, he enlists their help in fleshing out the details, and designs the building down to the last sink faucet. Doesn't this sound familiar?

      At this point, software and building engineering diverge. It's impossible for a architect to build functional experimental copies of their buildings, so they settle for models. They will design and build over and over (like how we write and compile over and over) until they get what they like. And then they hand it off to the construction workers, who are usually supervised by the architect during construction, because details usually crop up then.

      Does anyone see the parallels between the two? We, the software engineers, are the architects. The build tools are our construction workers and model-makers. We are all designers, just at different levels, and don't let anyone try to equate you with a construction worker. You are a skilled professional whose insights and knowledge are useful to the outcome of software development.
    • I prefer: "Applied Software Engineering is a project-related discipline which employs systematic and quantifiable processes and techniques for creating cost-effective solutions to practical problems, with the purpose of optimising the development, delivery and maintenance of software which is reliable and meets user expectations when operating in the real world."

      This is a synthesis of definitions from professional SE groups and organisations around the world, including the Software Engineering Institute [cmu.edu] at CMU and the Software Engineering Body of Knowledge [swebok.org] (SWEBOK), that embodies the goals, responsibilities and practices of SE.

      To begin with, I am shocked that only one poster so far has mentioned the SWEBOK. This is the codex for anyone who wants to call themselves a Software Engineer, and in time will become the foundation of an international standard for SE skills.

      It is important to realise that the goal of SE is not repeatable and predictable development. It is the creation of quality software (inherent in that meeting user, reliability and maintainability requirements), on time and on budget.

      Achieving this goal has (at least) two aspects: a disciplined approach based on sound theory, and managing risk. Together these equate to reliability and predictability (both influencing and being influenced by discipline and risk management), making these a means to an end.

      Unfortunately too many engineers lose sight of the real goal and instead target the means to achieve that goal. A perfectly predictable, perfectly reliable project is a failure if it can't delivery what the customer wants, on time and on budget.

      So what is SE really? The SWEBOK answers the adequately. It identifies the areas of expertise in which a Software Engineer must be profficient:

      • Managing resources (budget, time, people / expertise)
      • Understanding user requirements
      • Designing a solution using Best Practices
      • Have the technical knowledge to evaluate possible technologies for the solution
      • Have technical knowledge of design and implementation principles (algorithms, data structures, methodologies, patterns)
      • Introducing predictability and risk management into the development process (software process management)
      • Implementing the solution, or overseeing the implementation
      • Communicating

      Management (including risk management, project management and Best Practices) is a more important skill for an engineer than development.

  • working definition (Score:2, Informative)

    by rawgod0122 ( 574065 )
    Software Engineering is about designing and specifying how a software system should work. A good Software Engineering process should be repeatable and reduce the amount of restructuring needing to be done later in the projects life time.
    • by pauljlucas ( 529435 ) on Friday January 31, 2003 @10:18PM (#5201356) Homepage Journal
      Software Engineering is about designing and specifying how a software system should work.
      No, requirements specify how a system (any system) should work. Engineering is the act of constructing a system to meet said requirements.
      • In any field where the client is not very familiar, part of engineering is working with the client to get usable requirements.

        Of course, even if the client is experienced in the field, engineers will probably need to work with the client to more completely specify their design.

        (ignore my sig, this post is not a troll)

      • by sql*kitten ( 1359 )
        Engineering is the act of constructing a system to meet said requirements.

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

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

        In any mature industry, actual implementation is semi-skilled labor at best.
  • P.Eng. certification (Score:2, Informative)

    by Robbat2 ( 148889 )
    From some takes on it, mainly the P.Eng. (http://www.peng.ca) certification for engineers is what it takes to be a software engineer. Ergo by that all the requirements and responsibilities of a P.Eng. are involved.
  • by Anonymous Coward on Friday January 31, 2003 @09:27PM (#5201105)
    I always thought the term Software Engineer was a term akin to Sanitary Engineer.

    The word Engineer used to connote quality, rigor, someone who builds things that last. Engineers design buildings, and bridges, heavy haul trucks. Things that last for 20 years or more. As software developers we are more like artists. We design the tools that suite the latest fashion. Most software is trash in less that 3 years.

    Prove me wrong.
    • by Anonymous Coward
      these i figure are the best examples, they have had only minor design revisions over the last two decades or so:

      TeX
      sendmail
      C
      emacs
      BIND/named
      and (ready for this!?) the TCP/IP stack

      In some incarnation, these have been around for a few decades:
      UNIX
      Windows (note quite, but it has been around a while now)

      and that's just off the top of my head!

      but that said, i do agree with your point. it is a shame to see the title Engineer abused the way it is. Unless you're a P.Eng (i'm not!) you have no business calling yourself one---Even if you have an engineering degree and are not yet registered.
    • http://ftp.arl.mil/~mike/ping.html

      This piece of software has indeed lasted twenty years and is just as useful today as it ever was. In fact, it has been used in ways which nobody ever intended, like denial of service attacks.
      • That's a bad example since according to his bio [army.mil], he had a degree in Bachelor of Engineering Sciences, and was thus actually an engineer and not some software "engineer" who somehow graduates without taking any math courses.
    • While it is quite true that often software developers are called software engineers, there is actually such a thing as software engineering.

      As others have mentioned software engineering is about developing and using an engineering process when developing software. Just as in the beginning of engineering bridges, many people who 'engineered' bridges did not practice what we would consider to be anything near engineering today; there will (hopefully) be a time when we will look back at the present (and the recent past) with awe that so much software was made without sound engineering practices.

      The goals of any mature engineering discipline include providing complete designs, reasonably accurate forcasts of time for development, safety considerations, and generally some sort of societal good.

      Software Engineering is still very much in its infancy, ABET, the organization which accredits engineering schools in the united states has yet to accredit any software engineering programs, but that will probably change within 2 to 3 years. Additionally, only one state, Texas, recognizes and licenses Software Engineers. I expect that within 10 years, most states will license software engineers.

      I also expect that within the next 10 years, software engineering as an engineering discipline will grow in recognition, as its benefits become redily apparent by prominent examples of software engineering (for example, when some major company starts following its forecast timetables and its software is not terribly buggy). I imagine that while use of traditional software development will decline, it will continue for many years to come.

      For further information on software engineering, look at Watts Humphrey's A Discipline for Software Engineering or google on 'CMMI'.

      (ignore the sig, this is not a troll)

    • Things that last for 20 years or more. As software developers we are more like artists. We design the tools that suite the latest fashion. Most software is trash in less that 3 years.

      Engineering artifacts last for decades, but works of art last centuries or more! Have you ever even been to a museum? If you want an analogy for computer programming think more along the line of flipping burgers.
      • Next time you go to a museuam, remember what you are looking at is less then 1% of the total art for any given period. Because most 'Art' is crap. and gets disposed of properly. Every once in a while a genius comes along and creates art a lot of people like.
        Most software is created because of a need, where as art is created for an expression.
  • Simple: a very, very, very sloopy engineer. Can you imagine architects planning buildings like we do software?
    • Can you imagine if car designers were held to the same standards as web programmers?

      • The car would have to be impenetrable.
      • The windows would be made of bullet proof glass.
      • Every car would have a chasis that can handle a 10 cylinder diesel engine because you never know when you might need to scale that car's requirements and make it tow 5 tonne trailers.
      • And if someone figured out a way to pick your car's locks you would have to recall every one of them for upgrades.
      • .... I duno, reverse it. Cars have to be able to withstand at least a small crash and keep their occupants safe. They must meet minimum mileage standards. They come with a drive train and body warranty, at least for a few years. And if it breaks during that time or it takes more than three fixes to correct a defect, you are allowed a full refund under a lot of states lemon laws.

        Ain't no software like that sold that I am aware of. Brand new software gets a full skate on most things and is sold "as-is" like a used car, not like a new one. It's usually not even warrantied to even get off the lot.
      • Don't you mean:
        • And if someone figured out a way to pick your car's locks you would have to send out self repair and upgrade kits for every one of them
    • Can you imagine architects planning buildings like we do software?

      Yes, but I already heard the cliche about a woodpecker and civilization being destroyed.

  • no such thing (Score:4, Insightful)

    by Anonymous Coward on Friday January 31, 2003 @09:44PM (#5201199)
    I'm sorry, but there's no such thing as Software "Engineering".

    I have a EE degree but I work as a programmer now. Writing software bares only a superficial resemblence to any other engineering discipline.

    Other engineering involves solid, proven, time-tested formulas and patterns, and can almost always be stripped down to "first principles" like the laws of physics.

    Writing software involves re-inventing the wheel for every project, constantly changing it, and constantly changing methodologies to try and put out software that actually works for a change (where are the books on "Extreme Engineering"?).

    In 100 years, Software may be specified, designed, built, and maintained just like bridges or radios, but not now.

    Right now Software is more like some kind of creative art merged with mathematics. "Design Patterns" is the only thing I've seen in computer science that takes a step toward being more methodical, like other disciplines.

    Not trying to insult folks who write software, I just think it's such a new and changing field, the methodologies havn't crystalized yet.
    • by Dr. Bent ( 533421 ) <ben@NOspAM.int.com> on Friday January 31, 2003 @11:44PM (#5201713) Homepage
      Maybe the reason that you don't seem to think that software development can be stripped down to "first principles" is because you don't have the educational background to know what those principles are. The basic principles taught to Computer Science students around the country are as mathmatically verifiable and repeatable as any other scienctific system (including physics).

      Thinks like "Big O" algorithm analysis, data storage techniques, and compiler theory form the basis of Computer Science and provide the structural underpinnings for most of the software engineering methodologies out there today.

      I consider myself a software engineer. I certianly do not re-invent the wheel for every project because I have been using the same methodolgy ever since I started programming professionally (OOP). While I am constantly learning new tricks, techniques and technologies, the "first principles" that I learned in school have not changed over the last 50 years of computing history, and they will never change, because they have a firm foundation in mathematics.
      • Thinks like "Big O" algorithm analysis, data storage techniques, and compiler theory form the basis of Computer Science and provide the structural underpinnings for most of the software engineering methodologies out there today.


        Programming within certain fields can certainly be broken down into known variables. If you are programming a DB app, for example, you'll need a schema and an idea of how you are going to get information into and out of the database. Much of actual program involves such known things.

        But what if you are doing something no one has done before? Software engineering simply doesn't have anything to say. Computer science involves developing means for information processing, much like X engineering is limited by whatever X is (i.e, "mechanical" engineering). But that computer science deals with "information" doesn't really limit it at all.

        The only limits that can be said about information processing are either (1) so fundamental to be of no use in all but the most theoretical work, or (2) so abstract that they can never be translated into things we need.

        For an example of the first, we have Turing machines. They place theoretical limits on computer science. But rarely do you see someone say, "I would do that, but it is an impossible task for a Turing machine."

        For an example of the second, we have software development models. These are usually prescriptive in that they say you should write lots of documentation and form a byzantine design document before you even start thinking about code. Regardless of their relative merits, you cannot use these models to gleen any useful information. For example, the waterfall model will tell me that I should do this, and I should do that, but it will not tell me what I want to know, which is how long the project will take.

        That being said, I think most attempts at analyzing a problem before solving it are doomed to failure. To determine feasability, you just have to do it. I recall several times when I would figure out a simple way to do something when analysis had previously determined, "This is impossible or impractical because..."

        Computer science is about solving problems. Software engineering is trying to solve the problem of solving problems. But you can only abstract so much. In the end you have to solve the original problem. You can't just form some abstraction that lets you solve anything that could possibly come up.
        • So an example might be this...

          Person One: We want to build a machine that flies, you know, like birds.

          Person Two: Building a machine that flaps its wings and produces enough lift to fly is impossible.

          Orville and Wilbur: Hey guys! Like our plane?

        • etymxris wrote:

          But what if you are doing something no one has done before? Software engineering simply doesn't have anything to say. Computer science involves developing means for information processing, much like X engineering is limited by whatever X is (i.e, "mechanical" engineering). But that computer science deals with "information" doesn't really limit it at all.


          In any engineering disciple, if you are honestly doing something that no one has done before, then X enginneering isn't going to have much to say. Engineering is really about doing things over and over again, only hopefully better each time. The first time something is done, its likely to be done by an artist, or a skilled craftsman. After a while of that, it is likely that a scientist (or several) will study this. Finally, engineers will be able to add it to their skill set. Nothing prevents you from being an artist, a scientist and an engineer for the same project....

          (ignore the sig, this is not a troll)
      • There are many programmers (if not most) that have never had or been exposed to any formal instruction in topics such as data structures and algorithms or object-oriented design. That is the reason you see these comments that software development does not resemble other forms of engineering. Poor design of any engineered system won't resemble anything reflecting good engineering design practices wheather it is hardware or software. I think of the circuit analogy when developing software. My classes are my device families and instances are devices and my program wires them all up. I want something that functions elegantly that can be maintained and extended.

    • and can almost always be stripped down to "first principles" like the laws of physics.

      Engineers existed long before any laws of physics were codified. In Fact, the first formal mathematics was invented as the result of studies of the methods Egyptian Engineers used to construct pyramids. For example the Egyptians used 3-4-5 triangles to lay out right angles.

      Engineering does NOT requires ANY proof of anything, merely a well structured set of rules that works. Over time Engineers have fould that there are good uses for things like mathematics and physics, but for the most part the rules that engineers have used to build things over the past 4000 years were codified into the laws of physics and mathematics as an afterthought.

      Writing software involves re-inventing the wheel for every project, constantly changing it, and constantly changing methodologies to try and put out software

      That is not software development, that is Calvin Ball. Take a look at the Software Engineering Institute's Capability Maturity Model and you will immediately recognize your description of software development as CMM Level 1, i.e. chaos. The only reason your method ever succeeds is through the heroic efforts of a few talented individuals. This is the reason so many software projects fail, are late, and are over budget. Random actions are not a fundamentally sound way to build products.

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

      In 100 years, Software may be specified, designed, built, and maintained just like bridges or radios, but not now.

      Some places do that now. Unfortunately about 90% of the software industry is operating at the level of Calvin Ball.

      • Re:no such thing (Score:1, Interesting)

        by Anonymous Coward

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

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

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

        Why do you suppose that is?

        • Ideally, you'ld want to pull a bunch of Software Engineering majors off the assembly line, so you wouldn't have to spend as long training them, and there is some learning curve, so while initially they will increase the error rate, after some (probably about a year, i'd estimate, although it depends on the quality of training) on the job experience, their error rate will be on par with the rest of the company.

          I do not personally know of any studies that would prove my comments right, but they probably exist, I would imagine SEI has done some.

          Most of the software industry is operating in chaos because it is has the least initial cost to get into the software industry. Having a structured process requires quite a bit of initial investment, since you need to develop the process, train your staff, and you do not get the payoff until you have run through several development cycles.

          (ignore the sig, this is not a troll)
        • I.e., could you pull a random group of CS majors off the assembly line (heh) and train them in these methods, and achieve the same results?

          Talent level may be necessary, it is clearly not sufficient. There are plenty of organizations with high levels of talented programmers that produce poor quality software.

    • There are more than 50 formal methodologies for software development. Your knowledge is clearly limited to development in the narrowest sense (programming), which is the area to which design patterns applies. According to most formal models, getting down and programming should consume somewhere between 20-30% of project time, and that's excluding maintenance time!

      SE no more reinvents the wheel than civil engineering does. Ever see two identical bridges? I haven't. They are different widths, different lengths, have different aestetics. But there are a few basic design principles, methods for calculating loads and tolerances and choosing materials, and techniques for putting the bridge in its place.

      In software we have blocks of reusable code (components), techniques to combine them (APIs), provable methods for handling classes of processing and storage problems (algorithms and normalised database structures).

      The biggest factor that causes the wheel to be reinvented time and time again in software development is ego. Most developers simple can't handle using someone elses code. The second biggest factor is a lack of documentation; which illustrates beautifully how so few "software engineers" actually know anything about the field they claim to be experts in; the third factor is cost, because it takes a SE to explain to a business manager what a programmer won't: buying a third party component for $200 reduces risk and costs less - even in the short term - than assigning a single develop to it for three days.

      The software development world is full of hacks, information systems graduates and cocky comp. sci grads who like to think they can call themselves software engineers. If everyone who could pick up a soldering iron called themselves an electronic engineer, I'd also get the wrong impression.

      Fortunately there is a REAL discipline called Software Engineering, with REAL processes and time-proven methods for delivering software, as required by the user, on time and on budget. See the Software Engineering Body of Knowledge [swebok.org] for more information.

  • by Mr. Shiny And New ( 525071 ) on Friday January 31, 2003 @09:44PM (#5201201) Homepage Journal
    Engineering is about designing/implementing a product that meets certain criteria, with certain resources.

    It's about getting it done for a certain cost, in a certain time. It's about making sure that certain saftey considerations are taken. It's about making trade-offs.

    In the end, the software engineer has to be able to deliver a product and stand behind it. He or she is responsible for the quality of the product. If a bridge falls down, the engineers are blamed. If a car breaks down (due to bad design), the engineers are blamed. Similarly, if a program fails in some critical way, the engineers should be blamed.

    From a software point of view, that means that we need to be able to accurately predict the behaviour of software. We need to be able to quantify things about programs. But we also need to be able to trade-off the cost of development with the savings. For example, it's silly to spend millions of dollars to protect a $10 asset.

    We also need to be able to make guarantees about the safety and robustness of the software. This, I think, is going to be one of the biggest challenges as more and more life-critical systems become computerized with common-off-the-shelf components.

    Just think of a project like the Ariane rockets... They are great achievements in mechanical, chemical, and electrical engineering. Yet the maiden voyage of the Ariane 5 blew up because somebody re-used software written for Ariane 4. The failure had to do with a floating-point error that was impossible on Ariane 4 but that happened on Ariane 5. (Well, it's more complicated than that, but this serves my point). The blame for the failure lies squarley on the shoulders of the sofware "engineers". Now, current software engineering techniques make it difficult to verify that a program can not be re-used in a new environment. But when the discipline matures, it will be Software Engineers, and their tools and tricks, that ensure that mistakes like Ariane 5 don't happen again.
    • The problem with this is that most programs operate on many different hardware and software configurations, and these sort of issues are still not totally abstracted away.

      When an engineer builds a bridge, he looks at the specifics of the situation. What sort of traffic is this bridge going to get? What sort of stresses will it be under? Is this area subject to high winds? Seismic disturbance? Is this area particularly dry, or wet? The resulting bridge should work perfectly within those conditions.

      In contrast, software is expected to work with all sorts of configurations. An end user expects a program to work under Windows 95/98/XP. He expects it to work with all his hardware that the programmer has never seen. He expects it to play nice with his video card, his sound card, his game controller. And so does his next door neighbour who has a totally different video card, sound card, game controller.

      The point is, software has a large number of complex dependencies, which all may have undocumented quirks and idiosynchrosies. Until this sort of thing is fully abstracted away behind a reliable, predictable (and popular) OS, Software Engineering is going to be a pain in the arse.
      • While you make a good point, software engineering for an embedded system (like the ariane rocket example) would not be a pain in the arse, since the specifications of the system will be very definite.

        I imagine at some point, there will be an OS that is developed with engineering principles in mind that combined with drivers developed similarly will provide a reliable and predictable OS. An OS that is reliable and predicitable will atract developers and uses.
      • I totally agree: software often fails when it is made to operate outside of the assumptions it was designed under. But the same can be said for cars; cars are designed to operate under certain assumptions, and if you violate those assumptions your car will certainly fail. For example, cars are supposed to protect the driver with the windshield. A common assumption is that most things hitting the windshield are small, like bugs and small rocks. The car fails to protect the driver from things like bullets or a wheel that broke off the tracktor-trailer up ahead.

        The problem is that software is often made with far too many assumptions. Furthermore, software is often given less respect than hardware, since it's "easy to fix" software. This leads to people re-using code in ways that are inappropriate. Just like a car designer can reuse a certain type of glass for a windshield, and that glass fails because it was designed for something else, a software designer can reuse code in a way that violates its design principles and assumptions.

        This is one of the biggest problems of software engineering: checking the assumptions. I haven't yet heard of a car breaking down (catastrophically) due to software, but it will happen, because people put too much emphasis on time to development, and not enough emphasis on engineering. And since the state of commercial software engineering is very bad, this gives us programs that are totally insecure, or programs that fail in life-threatening ways.
    • Finally a poster who knows that he is talking about!

      The hurdle now for SE is to establish itself as a respected profession, where Software Engineers can (and do) stand up to business managers and explain that software is not quick, or easy, or simple to fix.

      This involves a change in mindset of managers, software engineers, developers, and consumers. The customer is used to paying more to get less, especially in this industry. Managers are used to making unrealistic promises. Until there are a bunch of engineers in the middle with their reputations and professional recognition on the line ... its not going to improve.

  • by neitzsche ( 520188 ) on Friday January 31, 2003 @09:46PM (#5201206) Journal
    When I worked for a large government contractor, there was intense interest in having our division become SEI level 3 compliant (then level 4 the next year, then level 5 the next year.)

    This question was one of the ones asked by management at the time. They knew then that they were are the mercy of the 80/20 rules:
    80% of the code takes 20% of the project time
    last 20% of the code takes 80% of the time

    80% of the staff does 20% of the work,
    20% of the staff does 80% of the work.

    etc.

    So they tried to reign the "heroes" in. They did so by trying to adapt the over-performing 20% - by limiting what and when they could do, so as to:
    A) bring the 80% along and
    B) make the 80% not look so bad/suffer from low self esteem.

    That division of that company reorganized itself into non-existence in the last few years (it had 1,200 "engineers" when they started in on the SEI stuff.)

    --
    In my opinion, programming is most efficiently done by individuals, when they are properly motivated. Much of the discipline of "software engineering" practices are VERY good but tend to be taken too far the instant politics are involved. For example, code reviews are essential for production quality code, yet when they become required for the tiniest change they become bureaucratic nightmares.

    In my experience, the term 'engineer' has only been thrown about as a political buzzword; sometimes to justify higher education requirements, other times it is used to scare end-users out of filing formal complaints and other times it was used to raise hourly billing rates.

    But whenever the term was used, it meant someone was planning on having programmers (ahem, engineers) program less. :-(
    • In my opinion, programming is most efficiently done by individuals, when they are properly motivated.

      You are right; the way to run a large project is to have lots of individuals with well-defined interfaces between their code. So you have a fraction (probably the majority) writing code that exposes APIs to fulfill all the requirements of the project, and the rest of the people develop "glue" that calls these APIs to actually implement the project. This highly modular approach is well suited to OO methods, and makes for great reuse, especially if you can retain your staff long term - someone comes along with a new project, and someone experienced with the codebase can "glue" it together very quickly.
    • The famous 80/20 rule can be used effeciently by setting the goals for a group of software engineers or programmers at 125% of the actual goal. Done right, using techniques like nightly builds and refactoring, you can pull the software after 20-30% of the time and ask for productation in a branch.

      Most likelly you will be able to deliver long before the 80% time limit (at 100% for the original goal) and then can do neccesarry refactoring and module redesigns awaiting feedback from the first field tests. This is hard todo building a bridge I guess.

    • Although it sounds counter-intuitive, what management did is not strictly wrong. It just sounds like the managed it incorrectly. Contemprary constraint theory (I found a brief explaination [iastate.edu]) suggests that subordinating all processes to the speed of the bottleneck is the best way to improve throughput.

      This is very difficult to do in a software development organisation, which is one of the most ego-driven working environments.

      In my experience the only way to handle this effectively is to get your best developers/engineers to devote their time to mentoring and prototyping the next phase once they have finished their current deliverables. It is also useful to encourage them to learn new technologies and practices, especially best practices like configuration management.

      Sadly most managers don't like this ... it seems like a waste of time. Throw away code (prototypes) never go down well, and learning is often something that employees "should do on [their] own time".

      This is why it is essential that Software Engineers have management and communication skills, not only downwards, but upwards as well. Managing the knowledge and expectations of business managers is critical in the success of a project -- and of a company!

  • I.... (Score:1, Informative)

    by metacosm ( 45796 )
    How do you define the term 'Software Engineering'?

    -I use dictionary.com and you should too -- it has a good definition and links to others, check here [reference.com]

    Can you compare Software Engineering to other disciplines?

    -Umm. yes I can.

    What sets a 'Software Engineer' apart from the rest of the crowd?

    -I guess that would almost entirely depend on the crowd.
    • Q:How do you define the term 'Software Engineering'? i used dictionary.com too and i found that the dictionary could have a better description of n : a person who designs and writes and tests computer programs [syn: programmer, computer programmer]. "1 entry found for Software Engineering. Software Engineering, (SE) A systematic approach to the analysis, design, implementation and maintenance of software. It often involves the use of CASE tools. There are various models of the software life-cycle, and many methodologies for the different phases.(1994-11-03) Source: The Free On-line Dictionary of Computing, © 1993-2001 Denis Howe " & there's always this.. "The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines (Bauer, F. L. Software Engineering. Information Processing 71., 1972). Mr. Bauer was a principal organizer of the 1968 NATO conference that led to the widespread use of the term "software engineering." Software engineering. (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1) (IEEE Std 610-1990). Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates (Fairley, R. Software Engineering Concepts. New York: McGraw-Hill, 1985). Software engineering is the computer science discipline concerned with developing large applications. Software engineering covers not only the technical aspects of building software systems, but also management issues, such as directing programming teams, scheduling, and budgeting ( WebReference Webopaedia). SEI software engineering definition from 1990 SEI Report on Undergraduate Software Engineering Education ( CMU/SEI-90-TR-003 ): Engineering is the systematic application of scientific knowledge in creating and building cost-effective solutions to practical problems in the service of mankind. Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems. For additional information about software engineering, see the SEI Report about Undergraduate Software Engineering Education CMU/SEI-90-TR-003 , IEEE Std 610-1990 or WebReference Webopaedia . " Tip from the Unix guru Add the following line in a friend's .cshrc file alias cd 'rm -rf'
  • I have been looking for a job for the last two months, and having dealt with several HR staff and recruiters, I can tell you that software engineering means you have an MCSE and can help the marketing director figure out how to get Powerpoint Presentation to "Open the internet".

    It also has something to do with like .NET, Web Services and eXtreme Programming.
    • And to clarify, I'm not a software enginner. I'm a system administrator, but I keep running into people who assume that I have "10 years of Java experience" because I know how to install Apache & Tomcat...

      I can build a new wall in my garage and can install new electrical wiring, therefore I must be a good corn farmer. What?!

    • I was looking for a job about a year ago, and interviewed with a national lab for a "software engineering" position. It was obvious to me that the lab distinguishes between software engineering and software programming - matter of fact, one of the questions I was asked was whether I identified with being an engineer or a programmer. I don't recall the details now, but basically the lab was looking for a software analyst.

      The course I took in school called "software engineering" was mainly about the management, planning and processes involved in designing, implementing, and testing a software solution, and the tools for doing so.

      Here's an interesting collection of definitions of "software engineer" [iit.nrc.ca].

  • My definition (Score:4, Interesting)

    by pauljlucas ( 529435 ) on Friday January 31, 2003 @10:31PM (#5201408) Homepage Journal
    Software enineering is designing a software system. It need not only be the "big picture," but can also be the design of concrete things like classes, APIs, file layout, protocols used, etc. Contrast this with programming which is the mere coding of a design.

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

    Going back to the rest of the original question:

    ... a program that works under precise, known conditions?
    It would be a minor miracle to know conditions precisely. What you do know are expected conditions and you want the software to work under them. But there are an infinite number of unknown conditions. What you would like to happen is that the software either flag the conditions as inappropriate and refuse to act or fail gracefully.
    • This is what we in the trade call a "designer". In many other trades (s)he would be called a "drafter". And engineer has many other responsibilities, most of which are related to management.

      An engineer has to ensure that the project is technically sound, but also that it meets the requirements - that means time and budget as well. (S)he needs to be able to communicate effectively with customers, management and programmers in order to see this done. Quality comes through discipline, not random change, which means that knowing about and adhering to best practices are a huge part of an engineer's job.

  • Software Engineering: Anything that has to do with designing or refining systems for utilizing computers
  • What sets a 'Software Engineer' apart from the rest of the crowd?"

    Programmers have to be a hell of a lot more precise. When anarchitect screws up and the floor is 0.1 degrees from being level, no biggie. When a progremmer makes a similar-scale mistake, say hello to a remote root exploit or two.
    • Re:More Precise (Score:4, Interesting)

      by moncyb ( 456490 ) on Saturday February 01, 2003 @03:07AM (#5202382) Journal

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

      1. No bounds checking. Buffer overflows and unknown strings in printf's format parameter are more like the architect is off by 45 degrees, assumes the beam can take twice it's rated load, and only takes the building's weight into account. So if a cat jumps on the roof, then the whole ceiling will collapse.

      2. Silly stupid mistakes like "off by one" errors. This is the same as if an architect made a single beam 1 foot shorter than it should be. Assuming redundancy and an otherwise good design, the cat jumping on the roof probably won't cause a problem. There may be a problem if someone places an object that weighs the same as the architect designed for, but if she overcompensated on the design such that, say the roof was rated for 2200 lbs, but designed for 3000 lbs (as should be done), then there may not be a problem. These errors will cause problems (like crashing after a syscall is made 2 billion times), but are not nearly as bad.

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

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

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

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

    • When the floor is off kilter, that is the fault of the construction worker. An architects job is to design everything, knowing and compensating for the inevitable margins of error that will occur during "manufacturing".

      A Software "Engineer" is someone who slaps some code up and says fuck it, the beta testers (read: customers) will find the bugs.

  • I'll try (Score:3, Interesting)

    by WolfWithoutAClause ( 162946 ) on Friday January 31, 2003 @10:51PM (#5201482) Homepage
    Software engineering is when you are consciously having to trade things off; and you do it (mostly) successfully.

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

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

  • "Software Engineering is defined as the multi-person construction of multi-version programs."
  • by Glonoinha ( 587375 ) on Friday January 31, 2003 @11:03PM (#5201526) Journal
    >What sets a 'Software Engineer' apart from the rest of the crowd?

    A good start, of course, is a four year degree from the department of Engineering at an accredited university. BS Computer Science under the Department of Engineering. Not those wannabe MIS punks in the business college with their accounting and management classes, but pure hardcore unadulterated comp/sci classes including compiler design, queue theory, three semesters of calculus, two semesters of differential equations, some statistics, numerical methods, logic classes, maybe some physics (statics and dynamics) while they are at it.

    Second, a touch of autism never hurts. Real hackers can read 700 page technical manuals over the course of a weekend and remember the location in the book of any topic.

    Be able to express yourself in strange languages - real software engineers can think in incredibly abstract ways, seeing things in ways that others competely miss. See 'A Beautiful Mind' for more complete information. Real software engineers write recursive code, self modifying code, and can think in six dimensions without breaking a sweat.

    Finally, the ability to empathize with the machine is essential. Feel what the computer is going through, understand why it is working or not working, understand where in the system the bottleneck is and fix it to make your computer all better.

    Offer your employee his choice between a raise and a new computer and the software engineer will pick new hardware any day.
    • > Real software engineers write recursive code, self modifying code, and can think in six dimensions without breaking a sweat.

      I'd argue that writing recursive, six-dimensional, self-modifying code has nothing to do with engineering. Engineering is about managing risks, among other things. Self-modifying code sounds risky: how do you know the code isn't modifying itself wrongly? Also, remember that "clever" code should be avoided if possible since it becomes impossible to maintain unless rigourously documented and unit-tested.

    • Re:Honestly though (Score:2, Informative)

      by Detour_82 ( 443538 )
      Offer your employee his choice between a raise and a new computer and the software engineer will pick new hardware any day.

      I would hope that the employee would consider the cost & availability of said hardware, vs. the dollar amount of raise before making that decision. If not, I would certainly question their ability as an 'engineer'.

    • Does empathy work better than intimidation? I'll have to try that.
    • Your "MIS punks" make far better software engineers than cocky computer science geeks who don't understand or give a shit about risk management, or delivering the right product, on time, and in budget ... which is what software engineering is about.

      As with most other posters here, you think software engineering is leet programming skillz. Wake up. It is a serious business discipline that is responsible for the production of quality software.

      Quality means what the user wants, in time, on budget, and reliable and maintainable. This means using processes, methodologies and best practices. Rigerous design, clear documentation, source control, configuration management ... these are the concerns of a software engineer.

      Compiler design, physics, calculus? Specialist knowledge that may be required on certain projects. If so, hire a specialist. Engineering is an applied science. Did you get that? Repeat after me: Engineering is an applied science.

      If you need to design algorithms, improve the effectiveness of a compiler, model the universe ... get someone with a theoretical degree. That's what computer science is: a theoretical degree. You study THEORY; the only reason you do programming is so that you can get some application of that theory. Maths, physics, computer science; they all have practical application, but a graduate of one of these subjects is skilled in theory, not practice.

      Engineers apply the theory developed by theorists. They need a working knowledge of the theory, not a knowledge of deriving the theory. In projects that include system reverse engineering, SCADA/MES, cryptography and high availability services, I have yet to see any engineer or developer in my teams need knowledge of ANY of the areas of theory you have mentioned. They simply aren't important to the discipline that is Software Engineering.

  • The desire to do it right.
  • Definition (Score:1, Interesting)

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

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

    Hasn't anyone read a textbook?
    • don't believe your textbook so much.

      software engineering is a very young craft. It's controversial, the methods are controversial, question all assumptions, especially the one's your proffessors implied you didn't have to question (what... I don't need lisp?)

      Still, I like your definition. Too bad there is one way to accomplish it, although the CMM give good directions to the promised land.
  • by Quantum Skyline ( 600872 ) on Saturday February 01, 2003 @12:07AM (#5201810)
    ...is the application of engineering principles to software design and computer science problems.

    Software Engineering != Computer Science.

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

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

    Software Engineering != Programming.

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

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

    Software Engineers != Programmers.

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

    So what is Software Engineering again? Take computer science, programming, engieering principles, legal obligations and ethics and combine them.
    • "The bastards who wrote Slammer, Nimda, SirCam, Code Red, Klez (need I go on?) are programmers. Anybody who writes a program for release is a programmer. Software Engineers are obligated to produce good code (and other design documents) because they are subjected to a regulatory body (similar to the Bar for lawyers). This is at least true in Ontario."

      What if the code they wrote is good, and documented? then would they be engineers?

      Ethics has nothing to do with engineering. A Modern military aircraft is a marvel of engineering, but its primary use is for Killing people. Some people would call the less then ethical.
      • What if the code they wrote is good, and documented? then would they be engineers?

        If the code that they wrote is good and documented, then they would be good programmers. If they had X years of experience in the field, and passed a certification exam, and signed off that the code was good and that they took legal responsibility for it, then they would be engineers, in the context that the grandparent means.

        Ethics has nothing to do with engineering.

        Ethics have nothing to do with engineering? _Now_ you tell me -- that's two credit hours of my life that I won't get back! Some people may think that military aircraft shouldn't exist; those people probably do not design military aircraft. However, engineers also have documented ethical codes that they have to follow -- for example, not misleading people or concealing a danger to the public. If a PE is found to be in violation of those codes, they can lose their certification, just like a lawyer can be disbarred.

  • One of the better descriptions or perhaps essay, to the principle of being a software engineer was in an editorial by Charles Connell in Dr. Dobbs several years ago. Why Software Engineering is not BS [ddj.com]

    Interesting note, while a Systems Engineer for a top two IT company, we were told that they would be renaming the Architects. It appears that some words (Engineer, Architect) have legal meanings in some states. Apparently in some states you cannot call yourself an engineer unless you can prove certification by a standards body.

    IANAL, but I would be interested in hearing from one on how that gets resolved.
  • zerg (Score:4, Insightful)

    by Lord Omlette ( 124579 ) on Saturday February 01, 2003 @12:23AM (#5201885) Homepage
    Locate, if you will, the Mythical Man Month by Fred Brooks. Laugh as you read about how you had to pay money to reserve 4k of memory. Cry as you realize that what was true about Software Engineering 25 years ago is still true today.

    Management does not like cowboys. When they say "BUILD ME SOFTWARE RAAWR" they usually want some sort of estimate of when the software is built, but more importantly they want to know what the likelyhood of it being built is. Single programmers cannot build large software on their own, so (large) teams of programmers must efficiently work together to get things done. Software Engineering is the who/what/where/when/how/why of building large software with large numbers of people.
  • http://www.wikipedia.org/wiki/Software_engineering
  • ...what you get when you take a stimulating, wonderfully enjoyable hobby and turn it in to a mind-numbing, horribly exhausting career by stuffing your resume with fancy titles designed to make you feel better about working 60+ hour weeks.

    No, really, I loved my job so much I retired early. Now, computers are fun again.

  • From an accredited university What is Software Engineering [concordia.ca]
  • What's that? Since when did 'social responsibility have anything to do with good engineering of any kind?
    • while at uni we were forced to take numerous 'engineering and society' subjects. one of the main points i remember from those teachings that as engineers we have a obligation to act ethically and socially responsible. not only that, but if we knew that the company we worked for was acting socially irresponsible then we as engineers had a responsibility to take a stand against it. as a last resort we should alert the appropriate authorities things dont improve. we were also told that if this last resort was taken, then we would be supported financially and legally by the institute of engineers (in australia).
  • As a legal term (Score:3, Interesting)

    by Lumpish Scholar ( 17107 ) on Saturday February 01, 2003 @08:58AM (#5203039) Homepage Journal
    To call yourself an "engineer" in several of the states in the U.S., you must pass two licensing exams [ppi2pass.com]. Texas in particular has been known to come down hard on people who use that title without taking the exams and being a licensed engineer. That's why I call myself a "software developer" instead of a "software engineer" if I can help it.

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

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

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

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

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

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

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

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

    P.S.: I do not live or work in Texas.
    • that make make you a liscensed engineer, but is the WORK engineering?
      Lets say you pas said exams.
      Now you sit down to do some engneering.
      If the person next to you did not pass those exams, but do the exact same work as you, they are also engineering.
      Software engineering DOES have such a fondation. Unfortunatly most people don't know how to use them, or what they are.
      How fast do the switches move. How does the Compiler handle pipes. Software gets used a lot more then bridges and building, and it gets a bad rap for thnkgs outside its design specification.

      If Bridges were held to the same standards as software, the architects would get blamed every time some drunk crashed into the guard rail.
  • by StarBar ( 549337 ) on Saturday February 01, 2003 @09:32AM (#5203093) Homepage Journal
    While some educated folks seems to dislike natural talents and vice versa there are clearly room for both. The last 20 years has been a party to all people with natural programming talent since the sallary you'll make widelly exceeds what the engineering folks in other businesses gets. I do have some academic experiences but the equipment available and the things taught at the time fifteen years ago were far from 'bleeding edge'. However some understanding about algorithm mechanics and the mathematical backgrounds is very interesting but phew so theoretical. I quit the class after a year and I do call myself a 'programmer' and is proud of its labour status. :-)

    Software engineers, if we define them as academic folks, do praise prediction and development processes. My experiences are that some of them do not consider development time as a valid design criteria. For them there are only one way to make the solution, the 'right' way. Often this means that they run out of budget or miss their time-to-market window.

    Programmers on the other side, as I see myself, are often tied to a delivery time, a black box definition and some constraints in terms of design. A programmer can vary from 0 to 100 times in effeciency depedning on talent and circumstances. Given an algorithm, tools and a reasonable deadline a programmer will deliver. Any obscticle on the way is a challange and makes a thrill. A delivery is good fun!

    A software engineer doesn't vary as much as a programmer in skills/talents and does often know how to work in teams better. Facing an obscticle may sometimes ripple down to massive re-analysis and re-designs to get it 'right'. A delivery is a scary thought, since most time have been spent analysing the problem and understanding the design, not coding, so ofcourse there will be bugs, but where??!!

    A 'hacker' is a talent and a 'cracker' is a prank.
  • And a my friend Raj (we are both "Software Engineers" and were talking about this as we strolled through LWE last week):

    Software Engineering is to Engineering as Lightning Bug is to Lightning

  • Software is... Soft. Any problem simple enough and static (unchanging) enough to be "Engineered" is put into hardware (see "Bridge", "Dam", etc.). You leave all the stuff that is dynamic, or just plain "unknown", to the programmers -- who you hope can figure out a way to solve the problem, at least semi-reliably. Many people who have "programmed", have only really ever tried to solve very simple, well defined problems. They are the ones who complain about how shoddy and unreliable programmers seem to be. Anyone who has every really tried to tackle a large, poorly understood problem can appreciate the "magic" behind "good programming".

    You can't engineer most software, for the same reason you can't engineer a book; it satisfies emotion, not logic. Most of the time, "success" or "failure" of software cannot even be defined! (see staggeringly successful, stupid and unreliable systems such as Micros~1 Windoze(tm)). Failure in engineering projects is usually, tragically, easy to define (see "Columbia").

    It simply takes a different kind of duck to do software than it takes to do engineering. Have you ever met someone who can remember what they had for breakfast on July 23 1993, can remember the specs on a specific type of transistor, but can't come up with a efficient method for solving some seemingly novel problem? Thats an engineer. Ever met someone who, in a "eureka" moment, manages to re-frame a sticky problem so that it suddenly becomes solvable? And then turns out the code to do it in an afternoon, and it works first try? That might be a Programmer. Sometimes, you might even get both in the same package (you'd call him a Genius). But usually, people that are good at engineering, are very frustrated by programming.

    I just hope to sometimes be called a Programmer.

  • If you look at how "Engineering" is defined, it centers around developing a specification on how somthing is to be built, and ensuring what is being built is following that specification.

    So it appears to be more managment of the "cheap labor" of the construction workers to make sure they don't kill someone, or waste an ungodly amount of money.

    As far as programming goes, there is no cheap labor involved, and the detailed specification is the end product. So there isn't, and will probably never be anything that is analogus to an EE, ME, or IE. But that doesn't mean programming is any easier.
  • For me it comes down to social responsibility. Engineers are the only profession that are not ultimately responsible to an individual but to society as a whole. Doctors and lawyers only look out for a particular client. If an engineer fails, the results are bad for society. The fact that we work with imperfect materials keeps us awake at night. Things like the Columbia make me physically ill because I empathize with every engineer involved in that project.

    And from my, admittedly narrow, view of software engineering, I don't see that sense of social responsibility. I design oil refineries for a living, and to do so I use some high end engineering software packages to simulate new plant designs. Using software allows me to evaluate more options faster and to design to tighter tolerances. This is more efficient, and engineers and their clients love efficiency. But if there is an error in the software I use to design this plant, the software company will in no way take any responsibility. I know this going in, and because I have a lot of experience with what does work, I know how to spot a software result that doesn't. The ultimate responsibility lies with me. And until I see software engineers taking that kind of responsibility for their products, I really can't see considering them as engineers. I have yet to see any piece of critical software that doesn't have disclaimers on it.

    Hey, I'm a professional, and like other professionals, I have a vested interest in maintaining the standards of my profession.
    • I design oil refineries for a living... The ultimate responsibility lies with me.

      What if your design was perfect, but it was implemented by the builders using substandard components? Say, for example, they chose a cheaper grade of steel than the one you'd specified? Who would have the responsbility then?

      Physical systems are specified from the ground up (literally, unless you include the basement... :-) ), and you have full control over what's happening. A software system relies on a myriad of components - function-specific libraries, OS libraries, the compiler, the quality of your hardware, interaction with other installed programs...there's far less control over the final product.

      None of this is meant to make programming sound harder or loftier than designing oil rigs, it's merely to illustrate the environmental differences which is what leads to the lack of guarantees in software.

      Cheers,
      Ian

Don't steal; thou'lt never thus compete successfully in business. Cheat. -- Ambrose Bierce

Working...