Prev: When writing html table to div, the data from table is unformatted
Next: multi file download with one click
From: John Koy on 9 Feb 2010 18:02 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 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 |