Motivation of software professionals
in [Java Programming]
|
From: Nick Keighley on 11 Feb 2010 04:30 On 10 Feb, 10:42, Malcolm McLean <malcolm.mcle...(a)btinternet.com> wrote: > On Feb 10, 12:29 pm, Arved Sandstrom <dces...(a)hotmail.com> wrote: > > 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. > > > We need to get pushed from the outside, by purchasers of our software. > > Unfortunately that hasn't happened. > > Software management is not so stupid. sometimes it is. Sometimes quality is seen as being too expensive. The cost of a pissed off customer isn't always factored in. > If adequate procedures were > available that could ensure bug-free software, at reasonable cost and > time, they they would have been adopted. they are available, they do have reasonable cost (in many fields) and they have been adopted. Telecommunication systems mostly invisibly work. There's a good reason for this. > Except in a few areas > customers would soon shy away from 'no warrantry including the implied > warrantry of suitability for any particular purpose' products. we've pretty well brain washed the consumer to accept this as reasonable. > The fact is that many many formal methods are in existence. Some of > them might work, to some extent, and in some circumstances. But none > have really proved themselves when it comes to the acid test of > developing real software for non-trivial projects. talk to the telcommunications people, talk to the military, talk to avionics and space, talk to automotive (ok, bad example!).
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 |