Slashdot Mirror

← Back to Stories (view on slashdot.org)

Define -- "Software Engineering"

Posted by Cliff on from the what-do-you-think-it-means dept.

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?"

3 of 118 comments (clear)

  1. My definition by pauljlucas · · Score: 3, Interesting
    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.
    --
    If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
  2. Software Engineering... by Quantum+Skyline · · Score: 3, Interesting

    ...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.

  3. Re:More Precise by moncyb · · Score: 3, Interesting

    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.