From: John Koy on
Arved Sandstrom wrote:
[...]
> Engineering "certification" processes are considerably better and more
> comprehensive than anything that most software developers are ever
> exposed to. Starting with education - there's no requirement at all that
> software developers have a relevant degree or associate degree, or
> indeed any real SD training at all. Try that with prospective
> professional engineeers.
>
> It's not just entry-level certification that software developers lack.
> It's code of conduct, professional education, duty to the client,
> professional discipline and so forth. These are all standards. In order
> for software "engineering" to really be engineering it has to adopt
> similar standards.
>

As long as we disclaim all liability and give no warranties for the
solutions/products we build, SD cannot be an engineering field and the
term "software engineer" remains as an oxymoron.




From: MarkusSchaber on
Hi,

On 10 Feb., 00:28, Seebs <usenet-nos...(a)seebs.net> wrote:

> I don't buy it.  Software engineering isn't the exact same kind of thing
> as structural engineering is, or the exact same kind of thing as electrical
> engineering is, but then, those aren't quite exactly the same kind of thing
> either.

I personally think that the main difference between "Software
Development" and classical "engineering" is the level of abstraction.
Software development tends to have far more levels of abstraction, and
even their lowest levels of abstraction build on top of those levels
provided by the electrotechnical engineers.

http://www.artima.com/weblogs/viewpost.jsp?thread=255898 is also a
good reading on why software development is neither engineering nor
mathematics.

Markus
From: Seebs on
On 2010-02-10, MarkusSchaber <msr(a)soloplan.de> wrote:
> I personally think that the main difference between "Software
> Development" and classical "engineering" is the level of abstraction.
> Software development tends to have far more levels of abstraction, and
> even their lowest levels of abstraction build on top of those levels
> provided by the electrotechnical engineers.

This is true. However, I don't think that makes it "not really engineering",
any more than using a shovel means you're not *really* digging, just using
a tool provided by someone who makes digging implements.

Of course... It would make sense for me to think that way. Since I do
software development, and that means I spend a lot of time working with
many levels of abstraction, I tend to think that abstractions built on
other things are not all that different from the things they're built on.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Malcolm McLean on
On Feb 10, 1:02 am, John Koy <John....(a)example.com> wrote:
> Arved Sandstrom wrote:
>
> As long as we disclaim all liability and give no warranties for the
> solutions/products we build, SD cannot be an engineering field and the
> term "software engineer" remains as an oxymoron.
>
Basically no-one knows how to built bug-free software, so the lability
exclusions are necessary. They would be commercial suicide in any
other field. That doesn't mean there is no such thing as software
engineering, only that it is new and undeveloped. Boilers used to
regularly explode at the beginning of the industrial revolution, now
such accidents are almost unheard of.


From: Arved Sandstrom on
Malcolm McLean wrote:
> On Feb 10, 1:02 am, John Koy <John....(a)example.com> wrote:
>> Arved Sandstrom wrote:
>>
>> As long as we disclaim all liability and give no warranties for the
>> solutions/products we build, SD cannot be an engineering field and the
>> term "software engineer" remains as an oxymoron.
>>
> Basically no-one knows how to built bug-free software, so the lability
> exclusions are necessary. They would be commercial suicide in any
> other field. That doesn't mean there is no such thing as software
> engineering, only that it is new and undeveloped. Boilers used to
> regularly explode at the beginning of the industrial revolution, now
> such accidents are almost unheard of.

It's not a question of bug _free_ software. There aren't any other
fields I can think of where it's possible to get away with no liability
simply by claiming that it's impossible to achieve perfection.

It's also not entirely an issue of software "engineering" being an
infant field. The fact is that there exist adequate processes that apply
to every stage of the software lifecycle, and most software shops only
pay lip service to some or all of them. Doing proper requirements
analysis is not "undeveloped". Doing proper design is not "undeveloped".
Doing proper implementation in your languages of choice is not
"undeveloped". And doing proper testing and QA/GC is not "undeveloped".

In other words, we have adequate processes available but tend not to
adopt them. And _then_ because the products are seriously flawed we
disclaim liability because the products are in poor shape. That whole
mindset is not a problem that's going to be fixed by pushing for a
software engineering profession, because the desire for such a
professional status follows from a mindset that already follows the
basic principles in the first place.

We need to get pushed from the outside, by purchasers of our software.
Unfortunately that hasn't happened.

AHS