[dutchflyboy]

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!

[praptak]

I agree with D. Knuth here: software is an "art", but rather like in "artisan" not in "artist". In this context "art" means something that has some good established practices but is not yet science.

Full article here: http://www.paulgraham.com/knuth.html

This is a discussion about meaning of words, so appeal to authority finishes the argument :)

[dutchflyboy]

Hmm, good point, there is quite a difference. But still, I think most software problems wouldn't exist if there were more engineers (=theoretical knowledge) than artisans (=practical knowledge). But that's another discussion.

[sshumaker]

"(BTW, if you want, you could build a mathematical model of every program. 100% predictable)"

No, you can't - and provably so. (http://en.wikipedia.org/wiki/Halting_problem)

Even in the real world, you have user interaction - and their usage of your software isn't predictable, even if your code mostly is. Your codebase might be totally rock-solid, but users have a way of rapidly demonstrating that your assumptions were totally off-base.

There is some art, and some engineering, but the essence of programming is design. Every decision has costs and benefits. Design decisions aren't right or wrong in the abstract, you're simply trading off one thing for another - (Memory vs. CPU, CAP, etc).

The key is figuring out which benefits and which costs are most suitable for what you're developing - or more accurately, how the software will actually be used (not necessarily the same thing).

[Xichekolas]

> BTW, if you want, you could build a mathematical model of every program. 100% predictable

Have you ever tried to do this? Once you get past fibonacci functions, the amount of time and effort required is measured in PhD-man-years. And even then, all you have done is moved the risk from the code to the proof, because when you work on something that large, the risk that the model does not represent reality (either due to oversight, lack of understanding, or not correctly capturing the interplay between two aspects) becomes an issue.

[dutchflyboy]

True, but my point was that it's a bit stupid to say that software development wasn't engineering because it's not predictable. The problem isn't that it isn't predictable, but it's just so complex that errors are made, just like in any engineering project.

[Xichekolas]

But my point was that the complexity matters. If you throw complexity out the window, everything in the Universe is probably 100% predictable (unless you presume a deity with a sense of humor, or some other layer of non-determinism).

The issue is that the state space for software is so much larger than the state space for bridge building that we just don't have the tools to effectively model and predict yet. I won't argue that software is somehow an art, because I'm hopeful that someday we will have those tools, but I will argue that it's not engineering yet. The Alan Kay quote about pyramids in the article hit it spot on. We are still piling blocks on each other and hoping it works at this point.

[losvedir]

Don't forget:

>String theory, the most promising method of modeling quantum physics

Still a bit controversial to make that claim, isn't it?