Define -- "Software Engineering"

2nesser asks: "How do you define the term 'Software Engineering'? Some see it as the implementation of the theoretical world of Computer Science, but isn't there more to it than that? Social responsibility, documentation, a program that works under precise, known conditions? Can you compare Software Engineering to other disciplines? What sets a 'Software Engineer' apart from the rest of the crowd?"

Comments

working definition

[rawgod0122]

Software Engineering is about designing and specifying how a software system should work. A good Software Engineering process should be repeatable and reduce the amount of restructuring needing to be done later in the projects life time.

P.Eng. certification

[Robbat2]

From some takes on it, mainly the P.Eng. (http://www.peng.ca) certification for engineers is what it takes to be a software engineer. Ergo by that all the requirements and responsibilities of a P.Eng. are involved.

I....

[metacosm]

How do you define the term 'Software Engineering'?

-I use dictionary.com and you should too -- it has a good definition and links to others, check here

Can you compare Software Engineering to other disciplines?

-Umm. yes I can.

What sets a 'Software Engineer' apart from the rest of the crowd?

-I guess that would almost entirely depend on the crowd.

With All Due Respect....

[Dr. Bent]

Maybe the reason that you don't seem to think that software development can be stripped down to "first principles" is because you don't have the educational background to know what those principles are. The basic principles taught to Computer Science students around the country are as mathmatically verifiable and repeatable as any other scienctific system (including physics).

Thinks like "Big O" algorithm analysis, data storage techniques, and compiler theory form the basis of Computer Science and provide the structural underpinnings for most of the software engineering methodologies out there today.

I consider myself a software engineer. I certianly do not re-invent the wheel for every project because I have been using the same methodolgy ever since I started programming professionally (OOP). While I am constantly learning new tricks, techniques and technologies, the "first principles" that I learned in school have not changed over the last 50 years of computing history, and they will never change, because they have a firm foundation in mathematics.

Re:With All Due Respect....

[Dr. Bent]

How do you apply big-O and all the other CS stuff to "real" code?

Want a real-world example? Here you go:

I once wrote a rendering engine for a GIS data viewer. GIS (Geographic Information System) data, in case you're not aware, is huge. We're talking gigs and gigs of data in some cases. Because of this you can't just use a regular old 2D rendering system to draw it all on the screen because it won't scale up to be able to handle all this data. So when I was writing the replacement rendering engine, I make sure that all the lookup algorithms we used were O(log(n)). This is what makes rendering all this data possible, becuase you can find what you want to draw in logrithmic time (instead of linear time). I was able to establish this standard WAY before we wrote a single line of code. I could have just built a hashing system to look up the data in O(c) [constant time], but because of the algorithm analysis techniques I learned in school I knew that O(log(n)) lookups would be sufficent for the task (and save memory). So how many times did I have to re-write this rendering engine? Zero. I did it right the first time because I could prove the way I was doing it was performant enough to meet the spec before I wrote any code.

The reason that most of the code out there is terrible is because most programmers don't have (or don't use or don't remember) any formal computer science or sofware engineering training. Because of this, too much time is required to write really good code, so corners are cut. Software Engineering is not about establishing a draconian process to force developers to code a certian way, it's about providing tools and tricks to help them solve problems and prevent bugs with the least amount of effort.

Re:Honestly though

[Detour_82]

Offer your employee his choice between a raise and a new computer and the software engineer will pick new hardware any day.

I would hope that the employee would consider the cost & availability of said hardware, vs. the dollar amount of raise before making that decision. If not, I would certainly question their ability as an 'engineer'.

Re:abuse of the work "engineer"

[Anonymous Coward]

these i figure are the best examples, they have had only minor design revisions over the last two decades or so:

TeX
sendmail
C
emacs
BIND/named
and (ready for this!?) the TCP/IP stack

In some incarnation, these have been around for a few decades:
UNIX
Windows (note quite, but it has been around a while now)

and that's just off the top of my head!

but that said, i do agree with your point. it is a shame to see the title Engineer abused the way it is. Unless you're a P.Eng (i'm not!) you have no business calling yourself one---Even if you have an engineering degree and are not yet registered.

Re:Repeatability and Predictability

[JimMcCusker]

First Axiom of software engineering:

That which is repeatable and predictable is automatable.

Go ahead a credit me for that one. I don't remember if I got it from anywhere. The whole point of writing software is to releive people of tasks that are tedious and error-prone for people. If there are predictable, repeatable steps to produce something, then a program can be written to perform those steps. The worst term I've heard for the act of actually writing software is "software construction." Ugh. Compilers and project tools construct or, as most of you are familiar with it, build software. Does an author construct a book? No, the printer does.

What we do as developers is to design software. The design spec is the source code itself. We just have the privilege of having tools that construct from that design specification directly.

Architects (real ones, not the ones in software) will actually work on many levels in a building, not just the highest levels. There's the lead architect that figures out what the main uses of the building will be, and comes up with a general vision of how that building will work. Then, if he's lucky and has other architects working for him, he enlists their help in fleshing out the details, and designs the building down to the last sink faucet. Doesn't this sound familiar?

At this point, software and building engineering diverge. It's impossible for a architect to build functional experimental copies of their buildings, so they settle for models. They will design and build over and over (like how we write and compile over and over) until they get what they like. And then they hand it off to the construction workers, who are usually supervised by the architect during construction, because details usually crop up then.

Does anyone see the parallels between the two? We, the software engineers, are the architects. The build tools are our construction workers and model-makers. We are all designers, just at different levels, and don't let anyone try to equate you with a construction worker. You are a skilled professional whose insights and knowledge are useful to the outcome of software development.