IMHO, writing software is actually an excellent example of an engineering task. The reason we see all these failures in software development is, in fact, that most software developers are NOT engineers. This is where all this pain comes from.

The role of engineering is to apply a theoretical model/representation of a physical fact, in order to achieve a desired result. The role of science is to provide these models with maximum accuracy.

The better a model is (equations, empirical laws...), and the better the engineer masters this model, the more accurate will be the expected results.

Programming languages, frameworks and patterns are scientific models, designed to represent the working of a computer. Bugs and unexpected behaviors in a program are due to a bad application of these models. If you know exactly what you are doing (i.e. you have a deep understanding/knowledge of these models), there is no reason for you to observe some unexpected failures. The more experience you have, the better you understand these models, and the more productive you are.

Of course this is just theory: in practice, things are getting quickly complicated and it is humanly impossible to predict everything that will happen - that's why testing exists. But my opinion is one would see much less failures in software development if developers were actually experienced engineers. Many developers today have no idea what they are doing, essentially because they are juniors and inexperienced. Unlike engineers, they are not trained to mentally play with the theoretical tools they use, so they cannot predict the results. And yes, at this point software development becomes more an art than an engineering task. It's like juggling without being able to predict the trajectory of the balls.

I disagree with this guy, every point he makes is flawed:

> Engineering components exist in the real world

Yes, and computers don't exist in some alternate dimension. People might forget it sometimes, but if you're a real engineer, you should know how a computer works, and know it's not magic, it's physics that make you're computer work. Software is merely an abstraction. Secondly, math is also engineering, but you can't touch it, can you?

> Engineering components interact in more predictable ways

No, wrong again. Software is perfectly predictable (BTW, if you want, you could build a mathematical model of every program. 100% predictable). If you make mistakes in other engineering branches you can get some strange results too.

> Engineering has fewer fundamental midcourse design changes

I don't see the link between engineering and design changes here. Are you trying to say that no single engineering project changes during it's life? Just look at prototypes of cars, those changes are quite massive. Secondly, ask yourself this question: How much does it cost to change a rocket design midway compared to a software program?

> Is software development a science?

Well, that's the point, in my opinion it's engineering.

> Writing software is more an art than an engineering discipline

Some think so, but really, it should be seen as engineering. Why? Artists make choices related to what they like, how they feel. Engineers make objective choices (or at least they should, nobody is perfect).

Rant finished!

Algorithms are science and math. Programming is a craft. Programming in teams is communication and human relations. Making software that's easy and fun to use is psychology and arts. Selling that software is business and marketing.

It's the mix of all this that makes software development so challenging and fun.

Well, engineering is not like engineering. You can't paint all "engineering" and all "engineers" with the same brush: we're not all alike.

I've designed (physical) devices where the customer needed the end product ready in a few days, and others where it took months. Sound anything like software?

Software engineering is simply the process of using known concepts to build a software product. That's no different from "traditional" engineering. Just as you apply a different approach to a 3-page website versus an enterprise inventory app that must failover smoothly between 5 servers, a mechanical engineer will apply a different approach to designing a pickup truck versus a "Little Tykes" car.

The reason programs don't look like they're engineered isn't because we don't know how to (I'd like to think my software engineering degree counts for something), it's because we usually don't bother.

Does it really matter what you call it?

At the university I attended, the Computer Science program shifted from the Engineering department to the Science & Mathematics department during the course of my studies. Incoming freshmen were still handed copies of SICP and Introduction to Algorithms at the door.

Another factor: Many software projects are research projects, i.e. new technology development, because they try to do something new, whether on a technical level or on a user interface development level.

It is fairly common for new technology development to cost vast sums of money while yielding nothing practical. Importantly, when developing new technologies, people understand that something may or may not come out of it, and they accept that (somewhat).

The other factors are definitely an issue too, though:

- Lack of physicality of the output

- Increased likelihood of unintended interactions between components

- Clients changing their mind halfway through (!)

Computer Science in most schools is mainly mathematics and a couple of programming courses thrown in. To become a working programmer however is a craft that you learn and become better at through experience. The education that you get from Computer Science is similar to that you get from say political science. From political science you usually go to law school to learn something more concrete. Computer Science doesn't have a law school equivalent where you go to learn software development, usually you have to learn on your own. Depending on the type of software development work you do, you can find your Computer Science education quite useful. Basically any math heavy subject is a fine prerequisite education for software development craftsmanship.

A couple of questions that come to mind:

1.Is “Computer Science” the same term as “Software Engineering”? 2.Is developing specific applications for clients that ordered them Computer Science? 3.What about the cases when someone writes software for experiments and research in a specific field of science (for example biology)? 4.Is developing large enterprise systems part of the same field as is writing software that controls robots or for example software for optimization based on biological phenomena?

What do you think?

I prefer the title Developer to Engineer because it conveys the iterative work that is a large element of writing most software.

I disagree with points of this article, and I'm not sure about the premise. I think Software Engineering is not as well defined as it could be but I think it is getting better. The book Rapid Development by Steve McConnel goes a long way in that regard.

The article states that to spend vast sums of money and end up with nothing, you must be paying for software development. But if you follow the principles laid out in Steve's book (and probably other software engineering books as well), you can't end up with nothing; at every milestone you have something, just like a building.

I also disagree that software either works or doesn't. Most software problems are bugs, and most of the ones that make it through testing are intermittent, seemingly randomly occuring problems. Software with bugs still works, but may not be high enough quality that you would want to use it, similar to how you wouldn't want to live in a house made of shoddy materials, even though it still mostly provides shelter and "works."

Terence Parr (the author) is "the maniac behind ANTLR": http://www.antlr.org/

A tangential issue is the broken metaphor of "coding as construction", which is discussed in a classic essay by Jack Reeves: http://www.developerdotstar.com/mag/articles/reeves_design_m...

Software is an art because the tools, components, and abstractions are so incomplete, and so numerous, that it becomes impossible to calculate what will happen without trial and error.

The difference between engineering physical things and software is that in "regular engineering" the bulk of the decisions are made in the design phase. You might have issues that crop up during implementation but largely they are small in scope and can be resolved. In "software engineering" your design phase is short and the implementation phase is really long. Design decisions are happening during the coding part.

It doesn't have to be this way. If there were the equivalent of CAE tools for software design where you could easily manipulate modules and the interfaces between them maybe it would happen. (And no, the IDEs today are not there yet).

We need more standard high level reusable components that all the people on the team know. When I need something bolted together or need a simple motor, I've got a bunch of suppliers to handle that. Java and Python and others have these great comprehensive software libraries now, but they only go up to a certain level. I feel like so many software projects are just duplicating the same stuff over and over (exactly what RoR aims to solve in one domain which is why it is so popular). People have been saying this for 30 years now, but people were saying it in mechanical engineering for about 100 before it came to pass so I'm not surprised it will take a long time.

There is also the difference of modeling. When I'm designing something in the physical world I have a bunch of knowledge to apply to the problem. It's not as easy as people are making it out to be (bridges are not exactly trivial problems, especially when compared to 99% of the software written out there. Don't even get me started on what I work on) but there are guides. When I'm deciding what material to use for a part I have a bunch of information about the problem, a bunch of information about the available materials, and there will be some decision making process trading off several factors (cost, corrosion resistance, weight, strength, fatigue etc) and an informed choice is made. When I want to choose between Ruby on Rails and Django, I have a bunch of blog opinions. I can't model out the performance difference between using C++ or Java for a robotics framework. I can't predict what this algorithmn will do to my real time performance. You have to actually DO IT, and then measure it. Sometimes we have this in mech eng. too and we make physical models and test them on a small scale, that CAN happen in software engineering but rarely does it.

So 2 bit take away: the design phase in software engineering could be a lot more like "engineering".

I like the term "Informatics" pretty much describes what is the main topic in CS - so just being an Information Engineer/Artist is fine with me.

A Z80 can do almost everything that a modern CPU can do. Software is not quite so generic or fungible.

A lot of what we now call software engineering should really be sociological experimental design.

I've always had the opinion that "engineer" is what the americans call a programmer. I also maintain that the largest reason behind the increasing and worrysome trend of downright lousy and inefficient software is due to it being "engineered", or should I say "overengineered", rather than just programmed. I blame a bad part of "software engineering" for this downwards spiral, but not "software engineering" itself, even if there's always a very clear distinction in what software was done by a programmer, and what software was made by an "engineer", with the latter pretty much always being the clunky and inefficient one.

Art + Engineering = Software