Motivation of software professionals
in [Dot Net]
|
From: Brian on 10 Feb 2010 18:48 On Feb 10, 4:18 pm, James Kanze <james.ka...(a)gmail.com> wrote: > On Feb 10, 10:03 am, 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. > > Basically no one knows how to build 100% bug-free anything. > Witness Toyota. Globally, in fact, you can probably do better > with software than with most other things. And I've never > worked on a project where there have been liability exclusions > (which probably aren't legal anyway). Software from Ebenezer Enterprises is free. I think only an idiot would attempt to sue us for a problem they find in the software. I think the same things goes for Boost. I don't think they've ever been sued for defects. Brian Wood http://webEbenezer.net (651) 251-9384
From: Seebs on 10 Feb 2010 20:49 On 2010-02-10, James Kanze <james.kanze(a)gmail.com> wrote: > On Feb 10, 4:54 pm, Seebs <usenet-nos...(a)seebs.net> wrote: >> On 2010-02-10, Michael Foukarakis <electricde...(a)gmail.com> wrote: >> > 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. >> Why? >> Do you have any evidence to suggest that this kind of >> liability is actually reasonable, justified, and/or necessary? > Reasonable, justified or necessary, I don't know. But it's a > fact of life. If you deliver software, and it fails, you're > liable for it. Most of the time, the liability is spelled out > in the contract, but that still doesn't exclude any legal > guarantees the buyer may have. Ahh, there was some context lost in quoting. I was asking why such terms should be necessary to call something "engineering". Obviously, there are markets and/or projects where they are a practical reality, and others where they aren't. Since most of my work is in the free software world, I see a whole lot of software distributed without any kind of warranty whatsoever. -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: Seebs on 10 Feb 2010 20:51 On 2010-02-10, Arved Sandstrom <dcest61(a)hotmail.com> wrote: > Seebs wrote: >> I agree. I just don't think that rants about liability or certification >> are going to do anything. Neither of those has a thing to do with learning >> to write more reliable software. > Well, yeah, it does. Unless you believe that most software developers > and their employers are going to spend the extra time and money to do > all these things out of the goodness of their hearts. We already know > that the market will not force software quality to improve - it hasn't > happened yet. Not in general, but: 1. Some people will do these things because they believe it is important to do their work to the best of their ability. 2. Some people with contracts and such in place will still produce shoddy code. In short, while there's certainly a correlation, liability and certification are neither necessary nor sufficient to produce reliable software. Insisting on them strikes me as missing the point; they're a proxy value at best for the actual goal. -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: MarkusSchaber on 11 Feb 2010 02:45 Hi, On 10 Feb., 22:53, Andy Champ <no....(a)nospam.invalid> wrote: > Can any locksmith or > burglar alarm maker guarantee that a building will withstand all attacks > for 12 months? _That_ is the equivalent of withstanding all virus > attacks for 12 months - and it's on a far simpler system. Maybe not the locksmith itself, but there are insurance companies which calculate how high the risk is, and they take that liability. For locks, cars, even airplanes, insurance companies do that all the time. But there are only a few cases where this is done for software.
From: Arved Sandstrom on 11 Feb 2010 03:56
Seebs wrote: > On 2010-02-10, Arved Sandstrom <dcest61(a)hotmail.com> wrote: >> Seebs wrote: >>> I agree. I just don't think that rants about liability or certification >>> are going to do anything. Neither of those has a thing to do with learning >>> to write more reliable software. > >> Well, yeah, it does. Unless you believe that most software developers >> and their employers are going to spend the extra time and money to do >> all these things out of the goodness of their hearts. We already know >> that the market will not force software quality to improve - it hasn't >> happened yet. > > Not in general, but: > 1. Some people will do these things because they believe it is important > to do their work to the best of their ability. > 2. Some people with contracts and such in place will still produce shoddy > code. > > In short, while there's certainly a correlation, liability and certification > are neither necessary nor sufficient to produce reliable software. Insisting > on them strikes me as missing the point; they're a proxy value at best for > the actual goal. > > -s I agree with your specific statements. It's impossible not to - I see evidence often enough of software developers who have no relevant formal education, have no certifications, and have only OJT, who nonetheless have applied themselves in their own time to study their field. These are the people who read the formal language and API specifications, own copies of books on concurrency and software testing and software design, regularly read the better programming website articles, and subscribe to good articles. In fact, in some cases people who follow programming NGs on Usenet. :-) Generally speaking the majority of programmers who do these things do have some relevant formal education, and often certifications, but since currently a CS degree rarely prepares a person to be a good software developer it's not an important factor: what counts is the other stuff I mentioned. For sake of argument the fraction of such software developers may be 1 in 10. I doubt it's more, because in my 25 years or so in the field, spread out over nearly 35 years, I've encountered hundreds of developers in many different employment settings as co-workers and colleagues, and I've seen no evidence that it's higher than that. Here's the thing: the main reason for having the codes of conduct, required education and certifications, professional associations, regulated professional development, legal guarantees and so forth, is to prove to the consumer (employer of software developers, purchaser of computer software etc) with a reasonable degree of assurance that they are getting a known, reliable quantity, whether that be an employee or a product. All that stuff is there is to help regulate the market in software professionals and software itself, so that the consumer is not flying in the dark when it comes to choosing services and products. It's not a be-all and end-all by any means. It simply raises the bar, just as it does in existing professions. It's defining the minimums, and currently we truly have none. Such a system also protects the true software development professionals. As it is employers have a tough time selecting good people, and consumers have very little idea of what they are getting. Shoddy programmers can last a long time (and God knows they do), and while they're at it they damage or destroy the credibility of people who are really trying to do a proper job. Employers become accustomed to having mediocre employees, and customers get used to shabby software. When an employer gets an employee who really knows what they are doing they are lauded as superstars - well, they're not, they're just doing their job. And when customers get a reliable piece of software it gets 5 stars just for being good software, which is also pretty sad. The system should not be so hit and miss. And it does not have to be. You're quite right in a narrow sense. If you are talking about the 10% of developers who try, and the 10% of software shops that get it, and the 10% of software that is truly quality stuff, they don't need the extra push or the regulations. But the other 90% do. AHS |