7 ms·

Why writing software is not like engineering

91 points by nishantmodak 17y ago

mynameishere 17y ago
A Z80 can do almost everything that a modern CPU can do. Software is not quite so generic or fungible.
Legion 17y ago
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.
- InclinedPlane 17y ago
  The vast majority of college degree programs don't teach the core skills necessary for success in the field, regardless of naming, but that's a different problem. Nevertheless, naming has a powerful influence on understanding. If people think that software development is a science, they'll treat it that way, similarly, how they treat it will change if they think it's an engineering discipline or an artistic effort. I've come around to the idea that software development is partly engineering and partly creative, much like architecture. Treating it like a science is the surest recipe for failure, as you'll be lucky if you ship anything worthwhile on schedule. Treating it like engineering will result in a much higher rate of success, with higher quality, and greater scheduling certainty, but will frequently result in mediocrity and developer dissatisfaction. Treating it like pure art sans engineering will probably result in lower quality, and unpredictable scheduling. But giving proper respect to the importance of both sound engineering and creativity seems like the sweet spot to me.
- fauigerzigerk 17y ago
  What we call things shapes our preconceptions about how they work. But I agree, it's not very important what we call it. We have to go beyond preconceptions anyway.
oliveoil 17y ago
Terence Parr (the author) is "the maniac behind ANTLR": http://www.antlr.org/ http://www.antlr.org/
swombat 17y ago
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 (!)
erikstarck 17y ago
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.
- jonsen 17y ago
  Theory is science and math. Engineering is a craft. Engineering in teams is communication and human relations. Making artifacts that's easy and fun to use is psychology and arts. Selling that artifacts is business and marketing. It's the mix of all this that makes engineering development so challenging and (potentially) fun.
Ygor 17y ago
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?
- jpatte 17y ago
  1. No: The goal of Computer Science is to provide and improve methods, languages and frameworks to manipulate a computer. The goal of Software Engineering is to apply these tools in order to achieve a requested result with a computer. 2. No, that's the purpose of Engineering. (Science creates models, Engineering applies them) 3. This is engineering for scientific purposes :) 4. This is still engineering, applying different models.
frou_dh 17y ago
I prefer the title Developer to Engineer because it conveys the iterative work that is a large element of writing most software.
- bendtheblock 17y ago
  I always just assumed 'engineer' was an Americanization of the word 'programmer'/'developer'. Maybe that's just my British perspective. It's also down to my belief in some of the principles in the OP. I'd never heard 'software engineer' used outside of an academic discipline, until I got in to startups and listened to lots of US tech podcasts and read lots of US tech blogs.
  - michaelcampbell 17y ago
    > I always just assumed 'engineer' was an Americanization of the word 'programmer'/'developer'. It often is exactly that. I'm probably being too pedantic, but as a developer I don't allow myself to be called an engineer, though some companies have wanted me to. I'm not one, I don't have an engineering degree nor certification and I feel it cheapens the Engineering profession to allow that. I guess I could be called a "scientist" since I do have a CS degree, but that just feels weird.
    - frou_dh 17y ago
      It implies a degree of rigour that I certainly don't have. I'm conscious of being just a punkass with an inflated job title.
    - jasonkester 17y ago
      Indeed. I do have an engineering degree and the certifications that follow, and I don't describe my day to day work as Engineering. I'm a guy who programs computers and runs a little software business. No need to go adding silly titles to that (and if I did, I'd probably go with CEO anyway, since it's quicker to write.)
- nandemo 17y ago
  He's not talking about titles. Even in countries where programmers aren't called "engineers" there's a discipline called "Software Engineering".
wanderr 17y ago
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."
- cousin_it 17y ago
  > at every milestone you have something, just like a building. What? When you're building a building, you don't have something usable at each milestone.
  - marcinw 17y ago
    Of course there are milestones (that leaves you something usable) in construction! * Construction start * Foundation completed * Structure/Frame completed * Roofing completed * Interior Walls etc etc etc.. I'm not in the construction business, but anyone with even the smallest experience (like putting up a deck) can tell you what critical milestones need to be completed. You can't start the roofing without the supporting foundation and structure completed -- nor can you put up deck railings without the actual deck floor in place.
    - deleted 17y ago
      [deleted]
    - wanderr 17y ago
      That's exactly what I (and the author of the article we're discussing) meant, I find it surprising that there is any confusion on this point.
hackermom 17y ago
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.
dutchflyboy 17y ago
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 17y ago
  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 http://www.paulgraham.com/knuth.html This is a discussion about meaning of words, so appeal to authority finishes the argument :)
  - dutchflyboy 17y ago
    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.
- 17y ago
hoggle 17y ago
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.
- yardie 17y ago
  In other countries anyone that does anything computer related is an informaticien. I don't like it because it's used as a catchall for an entire industry (tech support all the way up to engineer). And, atleast in the US, informatics implies information science. A degree you get when you want to be a research librarian.
projectileboy 17y ago
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_main.html http://www.developerdotstar.com/mag/articles/reeves_design_m...
jpatte 17y ago
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.
- arethuza 17y ago
  "they are not trained to mentally play with the theoretical tools they use" That's because the actual theoretical tools that are in place from computer science are generally not practically applicable to 99.9% of the work that most developers do. A knowledge of lambda calculus, CSP, Turing Machines etc. etc. is of no relevance whatsoever to someone building a CRUD business application or (for that matter) another client for Twitter. Formal abstractions from other fields aren't of much use because the mathematical techniques used for modeling the "real world" don't apply too well to programs. "Programming languages, frameworks and patterns are scientific models, designed to represent the working of a computer" That an interesting idea - but as far as I can see, completely wrong. Scientific models are created (usually using maths, but not always) to provide logical structures that have predictive and explanatory powers - and have to be consistent with observed behavior and have be falsifiable. Programs aren't constructed to explain observed behavior of computers or to predict what computers will do - they are created to control (through layers of abstraction and translation) what the devices will actually do. So I don't think "scientific model" is the right phrase to use.
Eddk 17y ago
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.
- fnid2 17y ago
  That wasn't true in my school. While there were lots of math classes to take, there were far more computer science classes required for a BS in CS and more electrical engineering and physics classes required for a BSe in Computer Engineering. Six or 7 math classes total, vs 12-15 computer classes
- jasonkester 17y ago
  That's not specific to Computer Science. My Mechanical Engineering degree spit me out with just enough knowledge that I could go learn how to be a Mechanical Engineer. None of the things I did on a daily basis over the next year were things I learned in school, but I was able to figure them out because of the things I learned. That's the unspoken purpose of school (at least in the Engineering areas). Your degree doesn't teach you to do any specific job. It's a 4-5 year conditioning course for your brain. It weeds out people who won't be successful in a certain area, and rewires everybody else so that they can "think like and Engineer". So if you're complaining that School didn't teach you to write CRUD apps in Java, you're complaining about the wrong thing.
known 17y ago
Art + Engineering = Software
jared314 17y ago
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.
HeyLaughingBoy 17y ago
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.
krschultz 17y ago
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".
- sshumaker 17y ago
  Certainly no one here is trying to make it sound like undertaking a massive engineering effort (like building a bridge) is easy. It's damn hard, and harder than most software projects - and it takes a lot more time and people. But people do build 'models' on a small scale when doing development. They're called 'prototypes'. Except in this case, they're usually to prototype the functionality, to collect feedback from the users, and not to test the 'engineering' suitability of a given library or framework for the final product. Why? Because satisfying the engineering constraints is not the hardest problem - nor the most important one - and not by a long shot. You can replace pieces of your infrastructure, or write your own, if they don't scale to your needs - but if your product isn't compelling, that's a non-starter. The 'design phase' of most construction projects is mostly about making engineering decisions. The 'design phase' of software products is more about features, usability, and scope. While engineering plays a role, it's not the biggest one - and you can have plenty of success with bad engineering decisions. The great thing about software development is that if you're successful, you can go back and revisit your earlier decisions - and fix them if necessary. You can build a bridge that will last a thousand years, but with software it's more important to figure out where to build the bridge TO. Or whether people would prefer a ferry.
DaniFong 17y ago
A lot of what we now call software engineering should really be sociological experimental design.

91 points by nishantmodak 17y ago

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

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.

InclinedPlane 17y ago
The vast majority of college degree programs don't teach the core skills necessary for success in the field, regardless of naming, but that's a different problem. Nevertheless, naming has a powerful influence on understanding. If people think that software development is a science, they'll treat it that way, similarly, how they treat it will change if they think it's an engineering discipline or an artistic effort. I've come around to the idea that software development is partly engineering and partly creative, much like architecture. Treating it like a science is the surest recipe for failure, as you'll be lucky if you ship anything worthwhile on schedule. Treating it like engineering will result in a much higher rate of success, with higher quality, and greater scheduling certainty, but will frequently result in mediocrity and developer dissatisfaction. Treating it like pure art sans engineering will probably result in lower quality, and unpredictable scheduling. But giving proper respect to the importance of both sound engineering and creativity seems like the sweet spot to me.
fauigerzigerk 17y ago
What we call things shapes our preconceptions about how they work. But I agree, it's not very important what we call it. We have to go beyond preconceptions anyway.

oliveoil 17y ago

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

swombat 17y ago

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 (!)

erikstarck 17y ago

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.

jonsen 17y ago
Theory is science and math. Engineering is a craft. Engineering in teams is communication and human relations. Making artifacts that's easy and fun to use is psychology and arts. Selling that artifacts is business and marketing. It's the mix of all this that makes engineering development so challenging and (potentially) fun.

Ygor 17y ago

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?

jpatte 17y ago
1. No: The goal of Computer Science is to provide and improve methods, languages and frameworks to manipulate a computer. The goal of Software Engineering is to apply these tools in order to achieve a requested result with a computer. 2. No, that's the purpose of Engineering. (Science creates models, Engineering applies them) 3. This is engineering for scientific purposes :) 4. This is still engineering, applying different models.

frou_dh 17y ago

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

bendtheblock 17y ago
I always just assumed 'engineer' was an Americanization of the word 'programmer'/'developer'. Maybe that's just my British perspective. It's also down to my belief in some of the principles in the OP. I'd never heard 'software engineer' used outside of an academic discipline, until I got in to startups and listened to lots of US tech podcasts and read lots of US tech blogs.
- michaelcampbell 17y ago
  > I always just assumed 'engineer' was an Americanization of the word 'programmer'/'developer'. It often is exactly that. I'm probably being too pedantic, but as a developer I don't allow myself to be called an engineer, though some companies have wanted me to. I'm not one, I don't have an engineering degree nor certification and I feel it cheapens the Engineering profession to allow that. I guess I could be called a "scientist" since I do have a CS degree, but that just feels weird.
  - frou_dh 17y ago
    It implies a degree of rigour that I certainly don't have. I'm conscious of being just a punkass with an inflated job title.
  - jasonkester 17y ago
    Indeed. I do have an engineering degree and the certifications that follow, and I don't describe my day to day work as Engineering. I'm a guy who programs computers and runs a little software business. No need to go adding silly titles to that (and if I did, I'd probably go with CEO anyway, since it's quicker to write.)
nandemo 17y ago
He's not talking about titles. Even in countries where programmers aren't called "engineers" there's a discipline called "Software Engineering".

wanderr 17y ago

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

cousin_it 17y ago
> at every milestone you have something, just like a building. What? When you're building a building, you don't have something usable at each milestone.
- marcinw 17y ago
  Of course there are milestones (that leaves you something usable) in construction! * Construction start * Foundation completed * Structure/Frame completed * Roofing completed * Interior Walls etc etc etc.. I'm not in the construction business, but anyone with even the smallest experience (like putting up a deck) can tell you what critical milestones need to be completed. You can't start the roofing without the supporting foundation and structure completed -- nor can you put up deck railings without the actual deck floor in place.
  - deleted 17y ago
    [deleted]
  - wanderr 17y ago
    That's exactly what I (and the author of the article we're discussing) meant, I find it surprising that there is any confusion on this point.

hackermom 17y ago

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.

dutchflyboy 17y ago

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 17y ago
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 http://www.paulgraham.com/knuth.html This is a discussion about meaning of words, so appeal to authority finishes the argument :)
- dutchflyboy 17y ago
  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.
17y ago

hoggle 17y ago

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.

yardie 17y ago
In other countries anyone that does anything computer related is an informaticien. I don't like it because it's used as a catchall for an entire industry (tech support all the way up to engineer). And, atleast in the US, informatics implies information science. A degree you get when you want to be a research librarian.

projectileboy 17y ago

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_main.html http://www.developerdotstar.com/mag/articles/reeves_design_m...

jpatte 17y ago

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.

arethuza 17y ago
"they are not trained to mentally play with the theoretical tools they use" That's because the actual theoretical tools that are in place from computer science are generally not practically applicable to 99.9% of the work that most developers do. A knowledge of lambda calculus, CSP, Turing Machines etc. etc. is of no relevance whatsoever to someone building a CRUD business application or (for that matter) another client for Twitter. Formal abstractions from other fields aren't of much use because the mathematical techniques used for modeling the "real world" don't apply too well to programs. "Programming languages, frameworks and patterns are scientific models, designed to represent the working of a computer" That an interesting idea - but as far as I can see, completely wrong. Scientific models are created (usually using maths, but not always) to provide logical structures that have predictive and explanatory powers - and have to be consistent with observed behavior and have be falsifiable. Programs aren't constructed to explain observed behavior of computers or to predict what computers will do - they are created to control (through layers of abstraction and translation) what the devices will actually do. So I don't think "scientific model" is the right phrase to use.

Eddk 17y ago

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.

fnid2 17y ago
That wasn't true in my school. While there were lots of math classes to take, there were far more computer science classes required for a BS in CS and more electrical engineering and physics classes required for a BSe in Computer Engineering. Six or 7 math classes total, vs 12-15 computer classes
jasonkester 17y ago
That's not specific to Computer Science. My Mechanical Engineering degree spit me out with just enough knowledge that I could go learn how to be a Mechanical Engineer. None of the things I did on a daily basis over the next year were things I learned in school, but I was able to figure them out because of the things I learned. That's the unspoken purpose of school (at least in the Engineering areas). Your degree doesn't teach you to do any specific job. It's a 4-5 year conditioning course for your brain. It weeds out people who won't be successful in a certain area, and rewires everybody else so that they can "think like and Engineer". So if you're complaining that School didn't teach you to write CRUD apps in Java, you're complaining about the wrong thing.

known 17y ago

Art + Engineering = Software

jared314 17y ago

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.

HeyLaughingBoy 17y ago

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.

krschultz 17y ago

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

sshumaker 17y ago
Certainly no one here is trying to make it sound like undertaking a massive engineering effort (like building a bridge) is easy. It's damn hard, and harder than most software projects - and it takes a lot more time and people. But people do build 'models' on a small scale when doing development. They're called 'prototypes'. Except in this case, they're usually to prototype the functionality, to collect feedback from the users, and not to test the 'engineering' suitability of a given library or framework for the final product. Why? Because satisfying the engineering constraints is not the hardest problem - nor the most important one - and not by a long shot. You can replace pieces of your infrastructure, or write your own, if they don't scale to your needs - but if your product isn't compelling, that's a non-starter. The 'design phase' of most construction projects is mostly about making engineering decisions. The 'design phase' of software products is more about features, usability, and scope. While engineering plays a role, it's not the biggest one - and you can have plenty of success with bad engineering decisions. The great thing about software development is that if you're successful, you can go back and revisit your earlier decisions - and fix them if necessary. You can build a bridge that will last a thousand years, but with software it's more important to figure out where to build the bridge TO. Or whether people would prefer a ferry.

DaniFong 17y ago

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