Software Engineering vs Traditional Engineering

Software is rather good actually. Only a small percent of any of it is faulty. It could be improved but it is largely not considered worth it.Civil engineering is not as perfect as often supposed. There are plenty of defects from barely noticeable to catastrophic. The software world simply knows nothing about other engineering. There is an easy way to see: just check the references in software engineering books and papers and count how many point to other such disciplines: practically none.<p

In my opinion, software, if it is a form of engineering, is a very strange form. A mistake in one part of the code can potentially affect any other part of the code. Not only that, but the effect it has is practically unbounded. If we were making a car, then it's a bit like putting in a cup holder causing the fuel tank to explode.We can't efficiently reason about our designs because we can't efficiently build from reusable parts that are known to work. Sure that cup holder

The software world evolves much faster than any of the engineering disciplines and has fewer physical constraints. The requirements for software are rarely fully specified when construction starts. Software is faster to build, deploy and fix so getting it right the first time is not as important. The environment in which it is deployed changes rapidly and in entirely unexpected ways, which is not the case for things built by engineers. There are plenty of differences. In practice, software is mo

I think it's not so much about the 'physical' part as about the 'rigorous training, certification and qa assurance practices' part. Developing software is very different from constructing a building (I do both, not as an engineer though); software is new, almost each and every time, because once it's build, you can just copy it byte by byte. Developing software is about pushing the edge in an unconstrained space. Physical construction (buildings, bridges, roads) is about repeatability; rigorous

Software engineering is still very far from engineering. It's a young field and everything is still very experimental. Its practitioners are still debating whether a hammer or a saw is the best tool for inserting a screw, and whether to insert the head first or the tip first. Don't forget that the art of building bridges has a head start of several thousand years :)

Software development is more like a craft rather than engineering. If you are willing to pay for an app the same money you pay for a bridge than you will get the same quality and rigorous checking. But even then, there are less than 10 types of bridges in the world comparing to software which has to simulate every human activity and sometimes imaginary activities like games, all that in much higher levels of complications, constant changes of requirements and infinitely open for later changes th

"Because of that, people thought you should write software the way you build a bridge or a car."The reason people think that is because they have no idea how the engineering to build a bridge or a car is done.Note, the term is Software ENGINEERING not Software Assembly or Software Construction. The engineering work necessary to design a bridge or car is actually not TOO dissimilar to designing anything else. You have requirements (often vague, conflicting and changing) and cons

As an engineer myself (EE) I disagree completely with OP.Engineering is mostly about making tradeoffs.It’s not that software does things different that other engineering fields, it’s just that it faces different cost structures.Bridges, buildings and infrastructure face huge costs when making changes in the middle of the project. Some operations make changes almost impossible, or so expensive that they are considered impossible. The worst case scenario for software is starting over, but

Software is completely different from your typical other engineering fields. You just can't apply the same methodology there. In other fields such as building bridges you are quite often taking what has already been proven to work well and building it, while in software if you start to repeat yourself you are doing things wrong.

Building software is often compared to building houses. If civil engineers can design and create a very complex bridge or dam or whatever, and it keeps working for 150 years without breaking. Why can't us software engineers make software that will work without bugs for more than 10 minutes?Problem is, the two aren't really comparable.A while ago someone wrote an article that we are Software Gardeners not engineers[1]. And I think that comparison is much more apt.Software is malea