What differentiates software engineering from any other engineering discipline?

Question

Software engineering shares many of the same traits with other engineering disciplines (attention to detail, complexity to mastery). What do you think differentiates it? Please be specific and substantiate your answer.

Answer 1

I'm not a non-software engineer, but it seems most of the other types of engineering involve either physics, chemistry, or mathematics more heavily than in software engineering. There are exceptions of course (modeling applications for all of the above, and mathematics in many applications), but that seems to be the case for most of the work software engineers are doing.

Answer 2

The fact that the medium we work in is so malleable. Many software engineering processes have been adapted from other disciplines, but the fact that we can make a change to our artifacts in a relatively short amount of time seems to be both the saving grace and downfall of software engineering.

Answer 3

Engineers have to work within the bounds of the physical world.

Software engineers create their own (virtual) world, and write their own rules for it.

Answer 4

An important thing in my opinion is in the development process: With Software, it is easy (read: cheap) to create prototypes and to let many people test the product, and you can fix a bug after the software has been deployed. With all other engineering disciplines, you rely on some hardware you are developing and you can't simply duplicate the thing in a matter of seconds, to give it to some more testers. And when the hardware made its way to the customer, you can't simply deploy an update if he (or you) found a bug, unless the bug is only in software. But then, it's software engineering again.

Answer 5

The biggest difference between software engineering and other forms of engineering is that the rules of our game change constantly.

When was the last time that a Civil Engineer had to worry about the laws of gravity changing or a Chemical Engineer had to worry about a change to the Periodic Table of Elements?

In software, our knowledge base is shifting constantly. Every year we get new operating systems, programming languages, or frameworks. A large portion of what someone learned 5 years ago may not even be applicable any more.

In contrast, just about everything other engineering disciplines learned 15 years ago still applies today.

Answer 6

The replication process in software engineering is tiny compared to other engineering disciplines. Once we have designed, developed, and debugged our software, creating new instances of it is practically free. This is not the case in any other engineering.

Answer 7

I would argue that for the most part software engineering is not engineering. It is a craft. Ours is a field that is on 60 years old. We are still learning what can and cannot be done, and are not at a place yet where we can even properly ascertain the question surrounding the problem we are trying to solve. Hence the agile sort of software methodologies, working on the question the best you know how, and constantly ask yourself if the question is changing, then change with it.

Producing some software that satisfies users needs is a nebulous process in most cases. While we 'engineer' a solution, it cannot usually be vetted against a formula or any physical constraints. It simply does enough to get the user satisficed.

Answer 8

In software engineering the client has no easy way to measure progress. In a 9 month construction project for a house/bridge/whatever the client is likely to know something is badly amiss if the foundations aren't complete after 3/4/5 months. But in software there is always the myth of the project being 80% complete and just a few idealized developer days away from completion. It doesn't help that in software engineering the product can be built from the outside in, i.e. starting with GUI prototypes and finishing with database access.

Answer 9

Software products are something you do not have to plan as excessively as other engineered products. Let me take a often used example that - obviously - is not the best one but will work for this case.

When you are planning a new release of a car manufacturer model you typically calculate of a engineering cycle of four to seven years. There is a specification phase, a prototyping phase, a testing phase, an optimization phase and a delivery phase. These often do coexist in time and informations from the one phase will guide / enhance ohter phases. But no one will change the complete engine short before delivering the new car. That's simply because it is not possible.

On the one hand, the development of "hardware" is a non trivia. On the other hand, the time you ship the car you have to ensure that it will work 10 years unchanged. You cannot simply update it like a piece of software.

So engineers here will be more conservative. At least compared to a "normal" software vendor. even if there is a bug in Windows or a kernel error in Linux, you simply provide information and downloads so everyone can upgrade.

If every software developer would have that in mind, software would be much more stable. But delivery cycles would be hell and client change requests nearly impossible.

Engineering, on the one hand, has some aspects of the "virtuality" of software, but it has to be "more correct". If you are an architect, you cannot state: "Sorry that the bridge went down, but I couldn't apply an upgrade in time." - you have to think of all possibilities in advance. If possible. I think you then get very conservative in certain points... .

Answer 10

An important aspect of engineering is being able to measure things. How much is the project going to cost, how complex is the project going to be, how big is the end product going to be.

Software is difficult to measure. The best measurement of size is lines of code. But even this is fraught with difficulty since no real standard of what a line of code is exists. It can vary from language to language, from company to company and from project to project.

Software complexity is in a similar boat. How do you compare the complexity of two programs, even if they are written in the same language by the same team. Obviously if one was a data entry program, while the other was an Operating System, then the Operating System would most likely be more complex. But is it twice as complex, or ten times as complex or what? How does one measure this. You could use something like Cyclomatic Complexity. But this again is not the most precise measurement.

So essentially, quantifying basic aspects of software development is difficult, with a wide range of variability and interpretations of those quantities.

Answer 11

Software engineering is in its beginnings, whereas stuff like Electrical and Chemical engineering has become more well defined.

Software engineering is only recognized as a licensed profession in Texas (last I checked) in the United States, while you can be a Professional Engineer in most of the other engineering professions in any state.

Software engineering will become a more formal discipline eventually, when things are better figured out. You could read in the Mythical Man Month about the beginnings of Chemical Engineering in this century and how it came to be more formally recognized later.

Answer 12

The fact that you are dealing with abstract entities that do not have real physical counterparts (except other abstractions such as code).

In all other engineering fields, you are relating to physical forces and entities in nature.

Answer 13

Personally I believe Software Engineering is part Engineering but that's just 1 part of the whole. The nice thing about software development is that a developer can incorporate a lot of qualities in a product, a developer can be part Artist, part Engineer, part Architect, part Mathematician and probably several other jobs as well. I'm not certain how well other Engineering disciplines can combine all these facets.

Answer 14

Software product is intangible hence software managers cannot see progress; they rely on others to produce a documentation needed to view the progress unlike other engineering discipline where managers can see the product being developed.

Software development process is not standardized, we do not have a clear understanding of the relationship between software process and product type.

Many software projects are 'one-off' projects, thus, they are usually different from previous projects