Motivation of software professionals
in [Java Programming]
|
From: Leif Roar Moldskred on 12 Feb 2010 02:11 In comp.lang.java.programmer Brian <coal(a)mailvault.com> wrote: > > Imagine driving by a house and seeing a car in front with > this sign -- "Free car." Imagine the cook at a soup kitchen storing raw and fried chicken in the same container. Or imagine a company giving out away a free game as a marketing stunt and the game turns out to have been infected with a virus that formats the users' hard-drives. Or imagine the author of an open-source product not paying sufficent attention and accepting a patch from a third party which turns out to have included a backdoor, providing full access to any system where the program is running. -- Leif Roar Moldskred
From: Richard Heathfield on 12 Feb 2010 02:16 Wojtek wrote: <snip> > > So the decision to drop the century from the date was not only based on > management but on hard economics. It was common practice to take 6 bytes to store YYMMDD, despite the fact that 5 bytes is easily sufficient to store CCYYMMDD. <snip> > And at the time Y2K was created it was not a bug. It was a money saving > feature. Probably worth many millions. No, it was a bug that wasted a byte and threw away data. And it's still a bug - some of the "solutions" adopted by the industry just shifted the problem on a little, by using a "century window" technique. That will catch up with us eventually. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Nick Keighley on 12 Feb 2010 03:08 On 11 Feb, 09:58, Michael Foukarakis <electricde...(a)gmail.com> wrote: > 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. http://catless.ncl.ac.uk/risks > 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: Arved Sandstrom on 12 Feb 2010 05:29 Leif Roar Moldskred wrote: > In comp.lang.java.programmer Wojtek <nowhere(a)a.com> wrote: >> And at the time Y2K was created it was not a bug. It was a money saving >> feature. Probably worth many millions. > > Not really. Remember, you can pack 256 years into a single 8 bit byte if > you want to, but in most cases of the Y2K problem people had stored a > resolution of 100 years into two bytes -- quite wasteful of space. > > In some cases it came from a too tight adherence to the manual business > process that was modeled -- remember the paper forms with "19" pre-printed > and then two digits worth of space to fill out? Those got computerised > and the two-digit year tagged along. > > In other cases it boiled down to "this is how we've always done it." As to the first case, one large app I am familiar with is a J2EE modernization of a legacy mainframe program. The business users, for decades, have produced lots of paper, mostly for auditing reasons. All the printed output has gone into folders. When the mainframe program was written it included the folder concept, although the application entirely did not need it. Even better, when the application was modernized a few years ago, into J2EE, the developers at the time made strong representations to business to leave the folder concept, and all of its associated baggage, completely out. No such luck - it's still there. The folder concept has to be maintained in the application, maintained through transactions, all the book-keeping related to folders is also duplicated in the application, and it's completely irrelevant to proper functioning of the application. In fact it's completely irrelevant period, but try selling that. This kind of thing happens all the time, and it results from a failure to identify and model the real business processes, as opposed to the things that simply look like business processes. Back when they had typewriters the folders made sense...like in the '60's. AHS
From: Arved Sandstrom on 12 Feb 2010 05:46
Leif Roar Moldskred wrote: > In comp.lang.java.programmer Brian <coal(a)mailvault.com> wrote: >> Imagine driving by a house and seeing a car in front with >> this sign -- "Free car." > > Imagine the cook at a soup kitchen storing raw and fried > chicken in the same container. > > Or imagine a company giving out away a free game as a marketing > stunt and the game turns out to have been infected with a virus > that formats the users' hard-drives. > > Or imagine the author of an open-source product not paying > sufficent attention and accepting a patch from a third party > which turns out to have included a backdoor, providing full > access to any system where the program is running. This is what I am getting at, although we need to have Brian's example as a baseline. In this day and age, however, I'm not convinced that a person could even give away a free car (it wouldn't be free in any case, it would still get taxed, and you'd have to transfer title) and be completely off the hook, although 99 times out of 100 I'd agree with Brian that it's not a likely scenario for lawsuits. With software the law is immature. To my way of thinking there are some implied obligations that come into effect as soon as a software program is published, regardless of price. Despite all the "legal" disclaimers to the effect that all the risk is assumed by the user of the free software, the fact is that the author would not make the program available unless he believed that it worked, and unless he believed that it would not cause harm. This is common sense. I don't know if there is a legal principle attached to this concept, but if not I figure one will get identified. Simply put, the act of publishing _is_ a statement of fitness for use by the author, and to attach completely contradictory legal disclaimers to the product is somewhat absurd. It's early days, and clearly software publishers are able to get away with this for now. But things may change. AHS |