Motivation of software professionals
in [Dot Net]
|
From: MarkusSchaber on 10 Feb 2010 02:49 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 10 Feb 2010 02:59 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 10 Feb 2010 05:03 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 10 Feb 2010 05:29 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
From: Michael Foukarakis on 10 Feb 2010 05:38
On Feb 10, 12:03 pm, Malcolm McLean <malcolm.mcle...(a)btinternet.com> 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. Nobody knows how to build earthquake-immune buildings, yet engineers give certain guarantees. When those are failed to be met, (s)he is held liable. Maybe it's about time some "software engineers" were held liable for their unreliable code in the same way. > They would be commercial suicide in any > other field. I don't see structural engineering or computer hardware engineering going anywhere anytime soon.. > 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. That's absolutely right. But we can't sit and wait for software development to be refined on its own, we should probably do something about it. Collectively or whatnot. |