I disagree with your choice of definitions for "engineering".  Most definitions I've read include "applying scientific knowledge" or "the application of scientific principles".

Scientific principles or knowledge being that of a methodological process.

Its the methodological process that is considered the Engineering.

I'll agree, everyone who produces software (notice I didn't even qualify it with "write"...) is not performing Software Engineering.

Arguably, if software engineers could draw on a better/defined body-of-knowledge or discipline like Civil or Electrical Engineers, software would be in a better state.  But, I don't think that precludes the field of "Software Engineering".

I could not agree more.  Software development is an art form, not a science.

The really sad thing is that business tend to not understand this, but developers do.  This differing mind set leads to many of project failures we know and read about.

  Writing software is definitely  engineering - Only an immature one.  It took thousands of years for the construction industry to get to where it is today.  Some day, we will be able to estimate and schedule  Software Projects  just like Construction projects. Till then - Happy Churning.

You mention that every software system is different. How does that disqualify it as being engineering? There is only a certain number of ways people want to cross a river. There's a certain number of techniques that have proven to work when building bridges, people follow these architectural "patterns". It doesn't mean that tomorrow someone can't come out with a new one. In software, the needs are just larger. The difference with software is that there are broader needs.

Regarding estimation, again, it's directly related to the needs of the customer. You can't ever give an exact figure or time line, but you can give pretty good estimates. This again applies to all engineering. Mishaps can happen and requirements can change when building a house too.

I agree that it can't be classified as manufacturing, but engineering, I think there are many aspects that resemble it. Is it art? Yes of course it is art, but so is building a bridge, so is building a house, they all involve a process of design.

I think both arguments hold and I know most of you are going to call this academia but I think the definition of engineering does hold for software. It's just the level that you are at is what lets you call yourself an engineer. If you’re just putting buttons and labels on a form or web page and have never even thougth of applying Demorgan's law on If-Statements that some developer hands to you and you have to know where that person is going wrong then you are not even close and may not even have the privilege of being called a programmer. Now if you are proving an algorithm using induction or any other type of proof technique “to” guarantee a curtain behavior for n case then you are now diving into a science. Remember that true programmers are known as Computer Scientists, we go through a lot of computing and logic that most “Physical” engineers go though to get there degree and should be shown some type of respect. You say that building a bridge is nothing like building software and that is true, but in both cases we have to make sure that it’s not going to fall under extreme circumstances as in too much load or abuse right? Well I think this is a counter example that should be thought about. On a brighter side, great article!!

I find it amusing that our industry uses terminology such as architect, framework, and engineer; yet we deny ourselves the title of engineering.

Some people like to believe that their code creations are art, just like an architect would like to think the building he designed is art.  To some respects this is true, but in the end the architect still had to work in the boundaries of physics. We are not confined to boundaries of physics, but eventually time to market, testability, and stability of applications will be the factors that cause us to evolve into higher disciplined levels of engineering practices.

Is this coming from IEEE Software magazine's Feb 2007 article by Raghavendra Rao Loka (basically saying the same thing; that software development is not software engineering)?

www.hacknot.info/.../showEntry is an interesting blog entry on that article and Steve McConnell's response...

*some* software development may not be done by some people based on "scientific knowledge"...  But, by and large, software development is performed methodologically and using Scientific Method.

Eric, Loka's article isn't publicly available (only to IEEE subscribers); but the abstract can be viewed here: ieeexplore.ieee.org/.../freeabs_all.jsp (subscribers would have access to the full text).

Steve McConnell's response is publicly available here: csdl.computer.org/.../r4006.pdf

It's similar to saying because the thousands of sub-contractors that build a bridge don't need to know anything about the laws of physics, durability, composition, balance, etc. to do their job (i.e. they're just pouring concrete, or welding iron, or painting), building bridges isn't engineering...

Steve McConnell also explains in his blog:

blogs.construx.com/.../quot-engineering-quot-in-software.aspx

"*some* software development may not be done by some people based on "scientific knowledge"...  But, by and large, software development is performed methodologically and using Scientific Method."

Uh, 'Scientific Method' involves creating hypothesies and then coming up with tests to falsify them.

What the heck does this have to do with programming?

jdn: you know exactly how everything needs to be written?  No, you decide how something needs to be written by methodologically researching what will and won't work before you start writing, performing tests to prove what will and won't work.

For a lot of people that comes as second nature; but that doesn't mean it's not scientific.

I agree with author and think there are 2 main reasons why software is not completely engineering:

1. Traditional engineering deals with physical world, stable theories and proven scientific principles. Software development deals with unclear business and people needs, mental concepts  and empirical principles.

2. Software development relies a lot on the humans, how they can operate with these concepts and interpret these needs.

I have related post: softwarecreation.org/.../what-is-software-development

Eric,

Fantastic post.  As an ex-engineer turned developer I'd like to quibble a little bit.  True, software development isn't always very scientific yet, but there are some parallels to engineering -- mostly because engineering itself is also partly craft rather than pure science.  As a practicing engineer you resort to empirical means, statistics, and models to help rationalize decisions when the underlying forces are simply too complex to accurately calculate.  That isn't all that different than the way software development is generally an exercise in adaptation and learning.

When I worked on 250 million dollar petrochemical projects the designs were very incremental and based on constant refinement from early models.  Yeah we used tons of number crunching and computer models, but intuition, experience, and constant learning fed into the final designs.

And by the way, software development is soooooo much more enjoyable than "real" engineering.  

Once again, great post Eric.

Also from Steve McConnell, I think as a response to the IEEE article:

forums.construx.com/.../quot-engineering-quot-in-software.aspx

I think your comparison to bridge building is somewhat lacking. Yes, you can look at the last 40 bridges you built and see how long they took, but to pretend that you can then estimate with 100% accuracy how long your current project will take is naive. For example, the new Wembley Stadium was finished both way over schedule and way over budget? There have been hundreds of stadiums built all over the world so surely by your reasoning Wembley should have been finished on time and on budget. It's easy to believe that software engineering is 'special' in some way which makes estimating more difficult but I'm not sure that that's just not an excuse for people not putting the appropriate effort and research into making their estimates.

It strikes me as odd that people care whether software engineering is in fact engineering. If you wish to define engineering as being a physical/physics pursuit, then that your definition. Software design, development, maintenance, etc can go either way. On one hand you have z-prime style development that is more mathematical and strict, including efforts to consolidate concepts into "theory". On the other you have people who adore programming as an art form - similar to how some engineers (as you defined them) create physical structures that are more form than function.

The major difference is that people are willing to buy the "hobbyist bridge" because the state of the field is too immature to provide people with a "one size fits all" solution. If anything, I would encourage people to call proper software development methodologies (and their theoretical pursuit) less art and more engineering. Something needs to inspire people to go to school, learn how to properly do things, and to do them properly. Otherwise we will all be complaining about how shoddy the state of software is for a very, very long time.

Incidentally, it would be nice if you would have mentioned that Javascript is necessary to submit comments. It is a little annoying to type out an entire comment and learn I have to wait until I get to the office to submit the thing.

While you are picking at nits...

Whoever told you that engineering was "science" did you a big disservice.  Engineering is a craft by which you apply knowledge and technology and creativity to arrive at a practical end.  

Science is a methodology - a process that is applied like a tool by those who wish to prove or disprove a theory in a repeatable manner.

I've heard a lot of engineers blather on endlessly about how they disapprove of the term "software engineering".  I've yet to hear a reasonable argument as to why it cannot be applied - mostly it boils down to ignorance and a strangely protective clutch on the term "engineer".  I guess software is just the new kid on the block who isn't allowed into the club yet.

Curiously enough, David Parnas founded a Software Engineering program:

www.mcmaster.ca/.../software.htm

Pingback from  VeronicasLore.com »  Rejecting Software Engineering

I think most people can Identify that physicists, Architects, and laborers (all who on bridges) serve different roles, but fail to see the distinction between Computer Scientist and Software Engineers, when in fact they are synonymous.  Also Software is designed as much like a bridge is designed, through planning and application of knowledge.  The only difference is they play by the rules of physics where as we go by the rules of the development system.  And the stuff about software being art I agree with but you cannot tell an Architect that a house or bridge is any less art than your software, because it isn't.

As a registered professional engineer currently working as an Oracle dba / developer, I see many similarities between engineering design and software development.

When you're writing software to build robots and control systems, it's multi-disciplinary engineering. You could say that COBOL-like programming or web design isn’t engineering and given the number of hacks out there, you’d be right. But 20 years as an embedded systems developer leads me to know that there is definitely “software engineering”.

I disagree with much of this.  For one, to say that we do not work under laws means you have never programmed.  Each language has a list of laws.  Just because a java software engineer uses a different list of rules than say a perl software engineer, does not mean that they do not exist.  Each language has characteristics just as every different type of metal does.  When you build a bridge with aluminum there are different things to consider than when you make it out of steel.  The same holds true for programming in different languages.  And to say that bridge building is not like building software is flat out wrong.  You start with a list of rules (programming language),  laws (logic, memory limits, latency, and user stupidity), tools (development software and code repositories), materials (computers, memory, networks), specifications and a some vision ...how is that any different than creating a bridge?

Also, to say:

"Part of the issue is that programming systems are defined by the user's needs, which are infinitely varied across companies."

and use that as a difference between creating an engine or bridge or a car and creating software makes no sense.  Aren't brides, engines, and cars defined by the user's needs?  Isn't it people's needs that causes engineers to create things?  Is every bridge the same?

I can't go into all of the other points I disagree with because I am "fake" engineering software right now but I assure you there are many.

>> A programmer, as Fred Brooks puts it (The Mythical Man Month) IS LIKE A "POET (.....)".  There is a plethora of languages and methods for ACHIEVING THE SAME RESULTS in software development and none of them are exactly the same.

So, your poet is achieving the same results. Maybe he is also an engineer, then.

Eric seems like a bright guy and a good writer, but this post is unfortunately a good example of the kind of misinformation that people are spreading about software engineering.

While Eric's argument seems appealing and persuasive, his underlying assumptions (which he seems to present as facts) about real engineering are *way* off base. For example, his assertion early in his post that real engineering has "near perfect information on durability, composition, balance, etc." is idealized and not correct. When John Roebling designed the Brooklyn Bridge, for example, the properties of steel cables weren't well understood, and so he used a safety factor of FOUR in designing the cable supports for the bridge. Obviously that is not even close to "near perfect information."

Eric also says, "Look at the estimation problems we have in software" as if that somehow makes software different from other kinds of engineering. Can you say "Big Dig?" The largest "real engineering" project in recent memory, the Big Dig was originally estimated at $13 billion. The final cost was about $80 billion. In Seattle, the construction cost of the Mariner's baseball stadium ended up being nearly double the original estimates. There have been many, many cases like this, which I discuss in my book, Software Estimation: Demystifying the Black Art. Estimation error in software is not any better or worse than it is in other branches of engineering -- the key challenges arise when you have to estimate large, unique projects. Estimating the 40th similar house you build in a housing development is easy, but so is estimating the 40th similar customized version of a software product you deploy.

It's true that there are 10:1 differences in productivity among different programmers, but that's not unique to software either. There was an interesting study conducted in the 1970s that found that the 80/20 rule applies in virtually every discipline: 20% of the programmers write 80% of the code, 20% of the police detectives make 80% of the arrests, 20% of the NFL quarterbacks make 80% of the touchdown passes, 20% of writers write 80% of the best selling novels, etc. Eric's observation is valid, but it doesn't have anything to do with whether software is engineering.

Invoking David Parnas in an argument against treating software as engineering. Parnas has been one of the earliest and most prominent proponents of treating software as engineering. Indeed, he founded Canada's first undergraduate program in software engineering at McMaster University.

Eric's conclusion that "I don't think software development will ever be able to be defined as engineering in the traditional sense" is unfortunately a good example of the kind of uninformed opinion that I was talking about in my recent blog post. "Software Engineering Ignorance."

Software engineering already has been defined as engineering, we have an international standard that contains that definition, the field's two largest professional bodies have jointly adopted a professional code of conduct for software engineers, we have accreditation standards for university programs in software engineering, and we have numerous programs that have already been accredited.

The argument is basically similar to the old scientific proof that bumblebees can't fly. The logic seems convincing, except that they're already doing it!

I think software development differs from civil engineering and architecture along 3 dimensions:

1) One can use engineering formulas to validate a design ahead of time. Software is not subject to the contraints of physics, so your ability to validate a design ahead of time is very limited - it's possible for well-defined algorithms, but that's about it.

2) Models are not nearly as useful in software development as they are in engineering. Models and simulations of bridges and buildings get you pretty close to the reality of your desing without actually having to build it.  Things like ERD diagrams and various UML diagrams, e.g. Class, Sequence, are far less effective.

3) Buildings and bridges are designed *against* change. Once you've built something like that, there are no significant changes possible. On the other hand, any worthwhile piece of software is undergoing constant change, often fairly substantial over time.Would anyone consider adding a few stories to an existing skyscraper, ro adding a lane to a bridge? I doubt it.

A reader of my previous blog post on Software Engineering Ignorance pointed me to Eric Wise's blog

Hey Steve, your numbers on the Big Dig are way off. Initial cost estimate was less than 2 billion and th final cost is approaching 15 billion (but your point is correct).

I always saw engineering as application of known practices to solving problems. It holds true in electronics (I am an electronic engineer) and also in software.

Does the practices apply to every problem? No. That's where innovation comes in, and it builds on the foundation of the known practices. Again true in both every field I know and software.

So, I think software engineering is just that. I do think there's a difference than other engineering types: The penalty for building a bridge wrong (i.e. if it breaks) is  a lot more than building software wrong (i.e. if it breaks). For most enterprise software, there's an acceptable risk of not hitting the target. But according to the CHAOS report, this too is going the right way.

Wise's comments echo the biggest problem facing software today---we treat it as a creative endeavor, not an engineering discipline.

I have outlined and rejected each of his points in a response here: www.robbyslaughter.com/blog

A reader of my previous blog post on Software Engineering Ignorance pointed me to Eric Wise's blog

Pingback from  Followup: Rejecting Software Engineering - Eric Wise

While Engineering is often described as Applied Science, I find in practice it is also Management of Complexity. A solid-state physicist could, in theory, design a radio, but I'd hate to see the differential equations. An engineer knows to use simplifying models instead, and knows how to vary the design to make it manufacturable without compromising the requirement significantly.

I see this happening gradually in software development: the use of objects to model the real world; higher-level languages to get the developer's thoughts down more quickly; frameworks to provide consistent glue to hold parts together; rapid prototyping systems to more readily capture client requirements. I believe that over time these tools will improve, and the productivity of good vs poor developers will equalize somewhat. When that happens (and when we get better at determining level-of-effort from requirements), cost and time estimations will improve.

In some sense, it is the developers who insist that what they do is an art that may be holding the field back. I suspect an "artist" would resist new tools that would mechanize what he does. It would make his work less fun. And more like real engineering.

I've sat in on presentations given by a CMM level 5 group designing software to fly on satellites and am pretty impressed by how well they  get things done. Mind you, their client knows enough to limit requirement changes. As the saying goes, developing to requirements is much like walking on water: they're both much easier when frozen.

" In the other disciplins you simply can't ship a product that isn't finished, but we do it all the time"

You should do a search for "Galloping Tacoma Narrows bridge". ;)

Science is not Engineering. Science is about the aquisition of knowledge, Engineering is about making things (often, but not always) using that knowledge.

If you reckon that we have near perfect knowledge of physical engineering, explain to me how concrete sets. Last I heard, mankind knew a lot about about that at a macro level - volume, time, mix, heat generated - but still didn't understand the chemistry of the setting process. Or go and read Richard Feynman's "Personal observations on the reliability of the shuttle" and consider that NASA's engineers don't really understand their own engine's turbine blades.

Similarly, Science is not about logic. Logic is mathematics.

I don't get the 'Engineering is not artistic' thing, either. When did engineering and creativity become mutually exclusive? Software has creativity in it - but so do physical engineering - people want their new skyscraper to be beautiful _and_ stand up. Big engineering projects can also be astoundingly beautiful too - Millau bridge anyone? - and I don't think that they made something that beautiful using just engineering knowledge and past designs.

"Why is it that the community can't agree on a few ways of going about software design that are best?"

There are plenty of things that are generally agreed to be standard good practice, e.g. prototyping, source control, proper specification (yes, even in an Agile process), documentation, testing, requirements analysis - all things that apply to physical engineering too (well, okay, maybe not source control).

For me the clincher was an article I read in an IEE newsletter (I'm actually qualified as an electronic engineer) which discussed why projects fail. Of the 40 reasons they gave, over 30 of them applied directly to the software company I work for too.

I suspect that the resistance to 'software engineering' comes from two main sources - 1) that we're so bad at actually doing it (although in fairness, we've had thousands of years learning to put up buildings), and 2) it doesn't actually deal with bricks and steel and concrete. But then, there are plenty of engineers who don't actually work with those things either.

(It's interesting how we default to 'civil' engineering as our example of proper engineering - why not electrical, or aerospace, or mechanical?)

More from Parnas:

"Engineers, whether software or otherwise, can be expected to make extensive use of mathematics in the analysis of their products, including programs.  Those who refuse to do so are technicians, not engineers."

- Mathematics of Computation for (Software and Other) Engineers.

Software development, as widely practiced, isn't engineering, but maybe it should be?

The question is not whether software development is engineering or not but why don't developers take an engineering approach to software development?  One can (try) to build bridges without using an engineering approach as well, and sometimes you might (possibly) succeed.  

And to say that software doesn't have any laws is just silly (trying to be kind with my words).  Try to write a program that can tell if another program will stop or not (i.e. halt).  You'll run into one of the laws of software.  Also, any software domain adds many constraints on the semantics of programs.  

Further, design, creativity, is a big part of the engineering approach.  Design is about finding a solution (an algorithm, a layout for a printed circuit) and that generally involves a creative process (driven by trial-and-error or from the experience of others, e.g. with design patterns).  

Sure we can get away sometimes without taking an engineering approach to software development, and a lot of clients are happy to live with the risk for the reduced cost, but for big jobs, important jobs, life-threatening jobs, it is almost negligent to do so.  

Hi. My response is in my sig.

Pingback from  Manuel Klimek  » Blog Archive   » Understanding The Fuzz About Engineering In Software Development

Pingback from  Links for 2007-07-02 (Mostly about the hot debate whether software development is engineering) « Spinning the blog

Pingback from  Yes Virginia, there IS software engineering  - LinLog

Pingback from  Software-Engineering  » Blog Archive   » Software Engineering Manager

Pingback from  Software Creation Mystery »  Quest continues: What is Software Development?

Software engineering is an art and a science, and is as much an engineering discipline as any of the more well established ones. If not all people who develop software are engineering it, that doesn't mean anything, or else I could build a bridge using a few pieces of plywood and 2x4s and thus reduce the field of civil engineering to an art form. Please.

I agree with Mr Hatken.  People try to program without the engineering aspect then they wonder why they get outsourced.  I can get anyone to compile code and hand it off to another team.  I need people who know how to engineer a solution.  THAT's what makes you 10x as productive.

As far as estimating, poor estimating is part of engineering (unfortunately).  When is the last time a road or bridge got built on time?  

Is software development engineering or artistry? This long running debate received new life when Steve McConnell gave a fiery reply to an IEEE Computer article titled “Software Development : What is the problem?“. Eric Wise has now stirr.

You can't be called an Engineer unless you graduate from an accredited School of Engineering. Period.

http://www.abet.org/

Having gone to a school of engineering I know what value they put on their accreditation.

Don't steel the hard earned title of Engineer. You have your own title that you worked for, software programmer, or whatever else.

Engineering programs are now offering Software Engineering.  In this case the title is fine. Your graduating from an accredited school and have the opportunity to get an engineering license like everyone else who seeks to call them self one.

I graduated as an Electronic Engineer (BSEE), and I work in software (and have for the last 25 years).

I think you can make an argument for software to be engineering, but I think a lot of this depends on what area of software you are working on. If you are simply taking values from a form and adding them together, I hardly would qualify that. However, if you are working in an embedded system where you have to develop a special fir filter to get sampled audio power spectrums at different bandwidths using a $1 pic, then yes, that qualifies as engineering in every true sense of the word.

I think the term came to be because traditional Computer Scientists were not qualified to work with computer hardware, but up at the business level using Cobol or whatever (I'm talking 25 years ago), and so, computer companies would hire EE's to do this work. These people, like myself, became and considered ourselves software engineers. We had engineering degrees! We developed software. Hence, we were software engineers.....that simple.

Since then, I have seen people with no official education who develop web pages and don't know the C language call themselves software engineers, and I cringe. I don't want to insult them, but in reality, I know deep down that these people are not engineers. They could not be saddled with an unsolved problem (as in never done before) and come up with a solution using mathematics to work out the appropriate algorithm. They just are not educated enough to do  that. They'd need a degree in some discipline like computer science (these days) or Engineering. I think the modern University graduate in any of these disciplines can call themselves software engineers. I do think there is a discipline. The problem is that organizations like the IEEE have become somewhat reviled by their own communities (except for academia). I think they are nothing but a ripoff in membership dues and the outrageous charges for viewing their magazines or papers, which were donated free of charge for the world to see by the writers. So, if EE's like myself don't have much respect for the official engineering organizations, then we are in a quandry where we really don't know what qualifies as an engineer period. I think Eric Wise's paper is mostly wrong as all of the principles he mentions about building bridges and doing drywall do apply to software engineering to the exact same level. Schedules in software are just as good as bridges. There is a huge disparity in skill amongst all engineers....not just in software. Generally those who go into it for the money are going to be the worst, while those who were born to it and love it are generally the best. All usually suck at management :-)

I've even heard of garbagemen calling themselves sanitary engineers....OK?

So, I think really the qualification should be are you doing engineering work....i.e. Design, develop and code/debug......then yeah, you probably can call yourself an engineer.

-D

Pingback from  Software Engineering  » Blog Archives   » The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition

Pingback from  Software Engineering  » Blog Archive   » Rejecting Software Engineering

Pingback from  Software Engineering  » Blog Archive   » Software Engineering Tips for Startups

Pingback from  Software Engineering  » Blog Archive   » Software Engineer Says Cab Computers May Be Vulnerable

I just hate programmers calling themselves engineers when, they don't hold engineering qualifications and/or a membership to the Engineering Association of their country.

It detracts from the professional title of real engineers...  it's like garbos calling themselves waste management engineers or whatever the going term is now...

Engineering used to be a respected field, but these days every man and his dog is an 'engineer' of some bullshit or other.

Pingback from  Gaming, Programming, and Micro-ISV Hodgepodge » Confusion in the Software Industry

First of all, just because one is a programmer doesn't make them a software engineer. It works the other way around, though. I've taken an engineering class at PSU and engineering involves well-defined standards and measurements of performance and physical measurements. Software engineers measure software in terms of running time, efficiency, and virtual space occupation (memory, f.ex.), and construct software through the application of mathematics and logic (pure sciences) which is both very reliable and portable.

I realize that there are people out there who are ignorant of software engineering and/or computer science in general, but it's not hard to understand the analogy between software engineering and "regular" engineering. Also, who says one can't liken building bridges to engineering software? Both require extensive development and sound construction based on the most efficient and stable application of their respective pure sciences. Both rely on standards of measurement, time management (getting it done in the least amount of time possible), artistic design (layout of the bridge, or blueprint - flowcharts are our "blueprints"), and all within accepted boundaries.

Second, the difference between a software engineer and a "regular" engineer is that the former works with electronic signals called bits, software libraries and pre-engineered code modules while an engineer of the physical sciences works with actual material that you can (usually) see or verify the existence of via experiments (such as electrons). What goes into building a bridge? Planning, oversight, construction, design (which involves both artistic and scientific disciplines), managing time and money, efficiency of work, re-usability, etc. Gee, doesn't that sound like what happens when fleshing out an idea with software?

One more point: are software engineers artists? Are they scientists? Actually, no. They are both, but with obviously more emphasis on science. Approximately 80% of a software engineer's work is science, and the other 20% is art. Remember, software engineers not only have to utilize rigorous mathematics and write testable, quantifiable programs, but they also have to design the software and decide how its components interact with one another. Any code monkey can be handed a document describing exactly how things are to be done, but an engineer must work within those constraints AND make intelligent decisions on his/her own.

Take a look at these definitions and then tell me if software engineering or development is not art:

art (1. noun) :

a. An occupation requiring knowledge or skill.

b. The conscious use of skill and creative imagination, especially in the aesthetic sense.

Note that def. b didn't exclude the predicate, but added on to it the notion of aesthetic art.

Certainly, software engineering requires extensive knowledge and skill in applying engineering concepts to software, and building robust, stable software. They also consciously apply their skills and creative imaginations to devise ways to test software, write their code, and piece together the disparate chunks or modules into a cohesive software project. There you go. Check out the full definition of art at www.m-w.com and make up your own mind on this matter.

What you have to remember is that programmers constantly do stuff that has not been done before.

It's not like engineering in the sense of you need a new house, you have built lots of houses before so you know the steps. There are other computer related stuff that are like that: if you need a new computer, a re-install of the operating system and all your old software migrated. If you are a IT support guy you've done that thousands of times before so you can give a pretty exact estimate.

It's like engineering when you need an extremely long tunnel under a massive mountain and you're not really sure what kind of rocks you will encounter and what techniques you must use to aviod them. Such extreme tunnels are not like each other. That kind of engineering projects are constantly late and over-priced. Just like software.

That's the difference and that's the likeness.

I stumbled on this discussion rather late, but all the same I'd like to add my two bits worth.

Arguing about whether modern orderly software development practices constitute an engineering discipline is more semantic than practical.  I mean, really -- who cares?

When we talk about software engineering we are referring to orderly, systematic, and methodical software development in contrast to informal ad-hoc development (e.g. “code and fix”).  If anyone is more comfortable calling this by another name I personally have no problem with it.

But the fact is that the IEEE, the ACM, ISO, the SEI, the PMI, and many other reputable acronyms have adopted the term “software engineering”.  The term is now very widely accepted and used, so my suggestion is that we all bite the bullet and accept it.

E.M. Bennatan

Wow - I always love a philosophical debate that hinges on a dictionary reference.  Brilliant.

First of all, this is not the exclusive definition of "engineering", nor even the original.  Lesson: things change - defend the status quo at your own peril.

Second, to say that civil engineering (or other forms) is not also subject to vague requirements, poor estimation, and cost and schedule overruns is to ignore reality.

Third, to ignore the aesthetic (or "art" or "good" design) component in traditional, "physical" engineering is again folly.  Ever marvel at the beauty of a sky-scraper, or the Golden Gate Bridge, or even Apple's iMac?

Fourth, software engineering IS predicated on science - it's called computer science and mathematics.  Computer science is NOT about programming languages, compliers, and IDEs - those are the tools of the trade, of the application of the science.  These are the parts that you consider infinitely repeatable, and likewise civil engineering has its tools, such as cement, back-hoes, and riveters.  What is not "cookie cutter" are the solutions, the configurations of the various tools and materials to meet a real-world need. Sure, there are architectural and design patterns, but these need to be altered, integrated, or even extended to fit the purpose of the day - which is why you need an engineer, both for a bridge and for software.  But you also need builders to follow the plan, again, both for the bridge and the software.  Software builders are called software developers or programmer analysts, but they do not obviate the need for software engineers.

Fifth, to imply that "physical" engineering is not concerned with the variety of user's needs when designing products is simply debater's fantasy!  Just consider a car for a moment, perhaps a Subaru Outback to be specific: all-wheel drive and a high ride for a variety of road conditions, hatchback cargo area for hauling items big and small, folding rear seats for transporting very large items, individual controls for HVAC in the front and rear, moon roof with sun shield and vent or full open positions for a variety of weather and open-air driving experiences.  Just because you limit your reality when you focus too singularly on the "bridge" analogy doesn't mean that reality truly conforms to your limitations.

Actually, I could go on, but let's face it - your argument is a bunch of bunk, and all it serves to do is continue to justify the slow pace at which software engineering matures into the "true" aspects of engineering: standardization, accreditation, and certification.

I think that your view is quite narrow here; I do not know you personally so I cannot and will not assume that you are a narrow-minded person, but you seem to be focusing too closely on some very specific examples of mechanical engineering to disprove that software is engineering.  One thing you did prove is that software develpment is not a physical activity, but that is hardly useful information.

The examples you have focused on have all been static examples of building something.  If you compare that to a true parallel in computers, I can confidently say that "I am going to build a homepage in HTML today", or "By the end of this week I will finish a project that interfaces with the database".  But you are right that nailing down software deadlines never happens accurately.  But compare that to developing something that is not passive, like your bridge or drywall, like building a motorcycle, from the ground up.  That is for sure a feat of engineering, if one is even doing all the CAD/drafting for the parts and stuff.  Ever watch those chopper shows on TV?  They are always stressing about deadlines.  Bridges don't do stuff, they are passive; software does stuff, and it's development cannot be accurately timed.

Also, perhaps the most important point is that putting up a bridge or putting up drywall IS NOT engineering, it's construction.  If you use a template for a bridge you haven't engineered squat; that's like installing software.  I will tell you almost perfectly how long it will take me to install Half-Life 2, but it was 8 years late in development.  I can tell you how long it will take to put up drywall, sure, but can you tell me when you will be done developing the next generation of insulation material?  Development is engineering, not building stuff.  Your parallels are incongruous.

Software engineer (IT) makes me think of the job title "sanitary engineer" because software engineer and sanitary engineer are "engineers" only in title. For those who don't know, a sanitary engineer is just a garbage/waste collector. Likewise, a software engineer is just a programmer. It's insulting to real engineers such as electrical, mechanical, civil, and such engineers to be compared to a janitor and programmer. You don't call a technician or a mechanic, an engineer do you? So you should not call a software programmer an engineer either. The title should be left to engineers who studied and practice engineering in it's formal definition just like the title medical doctor should be left to real doctors and not nurses or technicians.

We bet there will plenty of interest in the latest brownstone condo conversion in Fort Greene despite the fact that the finishes aren't doing it for us. Why? The location. This one's at 10 South Oxford Street, just steps from the park. The three upper

nice post, and I agree 100% with what you said.  

Pingback from  Harish Raju Musings  » Blog Archive   » Rejecting Software Engineering - Eric Wise