Motivation of software professionals
in [JavaScript]
|
Prev: When writing html table to div, the data from table is unformatted
Next: multi file download with one click
From: Michael Foukarakis on 11 Feb 2010 04:58 On Feb 10, 6: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? I am not an expert at law, so I cannot reason about justification or necessity. However, I do recall quite a few "mishaps" and software bugs that cost both money and lives. Let's see: a) Mariner I, b) 1982, an F-117 crashed, can't recall if the pilot made it, c) the NIST has estimated that software bugs cost the US economy $59 billion annually, d) 1997, radar software malfunction led to a Korean jet crash and 225 deaths, e) 1995, a flight-management system presents conflicting information to the pilots of an American Airlines jet, who got lost, crashed into a mountain, leading to the deaths of 159 people, f) the crash of Mars Polar Lander, etc. Common sense tells me that certain people bear responsibility over those accidents. How can anybody ignore this? Do more people have to die for us to start educating software engineers about responsibility, liability, consequences? Right now, CS students learn that an error in their program is easily solved by adding carefully placed printf()'s or running inside a debugger, and that the worst consequence if the TA discovers a bug in their project solution is maybe 1/10 lesson credits. I was exposed to the same mentality, but it's totally fucked up. > > 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. > > 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. So what? We already know how to write more reliable software, it's just that we don't care.
From: Phil Carmody on 11 Feb 2010 05:05 James Kanze <james.kanze(a)gmail.com> writes: > On Feb 10, 10:38 am, Michael Foukarakis <electricde...(a)gmail.com> > wrote: >> 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 are. That's why independent contractors have liability > insurance. In that case they're *not* liable for their unreliable code. Phil -- Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
From: Seebs on 11 Feb 2010 09:10 On 2010-02-11, Arved Sandstrom <dcest61(a)hotmail.com> wrote: > 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. I don't believe that they can do this, because the key measures of quality are sufficiently orthogonal to anything we know how to test that it simply doesn't work out that way. I'd almost certainly fail any coherently-specified certification, because my memory's like a sieve, so any check as to whether I know even basic things will discover that, well, no, I don't. It's very hard to develop a test you can administer for "knows how to look things up" or "knows whether or not he knows something". Furthermore, I very much dislike the notion of the software industry becoming afflicted with the kind of thing that many engineering professions, or the legal profession, have, where certification becomes a way for groups doing certification to make a ton of money preventing people from doing work unless they pay the group a ton of money. Right now, any old person can try to put software up on the internet. I would not want to see that change, but I do not have any confidence that a "professional organization" would be willing or able to refrain from doing so over time. It is the nature of such organizations (like any other human institution) to seek ever-broader power and influence. > Such a system also protects the true software development professionals. Some, but it may protect other people from getting the experience they would need to *become* true software development professionals. Had I needed a certification to start doing stuff, I would never have made it. > 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. I think the harm they'd do in the boundary cases is pretty severe, though, and essentially irreparable, while we've found somewhat survivable ways for employers who care about quality to obtain it if they want it. -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: Lew on 11 Feb 2010 11:17 Michael Foukarakis wrote: > How can anybody ignore this? Do more people have to die for us to > start educating software engineers about responsibility, liability, > consequences? Right now, CS students learn that an error in their > program is easily solved by adding carefully placed printf()'s or > running inside a debugger, and that the worst consequence if the TA > discovers a bug in their project solution is maybe 1/10 lesson > credits. You say that like the developers were at fault. I cannot tell you how many times I've seen management overrule developers who wanted to make things right. It's been the overwhelming majority, though. I recall a manager in 1982 refusing to let a team fix the Y2K bug in the project. Many good developers have grown resigned to the policies and have given up pushing for quality. Many more use stealth quality - they simply don't tell management they're doing things in an unauthorized way that's better than the official process. Only rarely in the last thirty years have I encountered management alignment with known best practices. Nearly all projects I've worked on involved many programmers, dozens even. Parts are written independently of each other, often over a period of years. Often each part test perfectly in isolation and only reveal bugs emergently under production conditions. Many of those projects had large test teams. Products have passed all the tests, yet still failed to meet spec in production. Sometimes the provided test environment differed significantly from the production environment. Before you make the developer liable, you'd better darn well be certain the developer is actually the one at fault. -- Lew
From: Andy Champ on 11 Feb 2010 14:46
Lew wrote: <snip> > You say that like the developers were at fault. I cannot tell you how > many times I've seen management overrule developers who wanted to make > things right. It's been the overwhelming majority, though. I recall a > manager in 1982 refusing to let a team fix the Y2K bug in the project. > Many good developers have grown resigned to the policies and have given > up pushing for quality. Many more use stealth quality - they simply > don't tell management they're doing things in an unauthorized way that's > better than the official process. Only rarely in the last thirty years > have I encountered > management alignment with known best practices. </snip> In 1982 the manager may well have been right to stop them wasting their time fixing a problem that wasn't going to be a problem for another 18 years or so. The software was probably out of use long before that. Right isn't necessarily perfect, or bug free. It's kind of important to be able to sell the thing and get the income for the next release. The trade off of course being (1) if you do it right you won't have to do it again and (2) if you do it really badly there will be no further sales anyway. We offer no warranty on my current project. We also know that if we screw up badly enough we'll be job hunting in six months - the trade will go elsewhere. Andy |