Motivation of software professionals
in [Dot Net]
|
From: Brian on 11 Feb 2010 15:33 On Feb 11, 3:07 am, Arved Sandstrom <dces...(a)hotmail.com> wrote: > > Free (as in beer) software brings up an interesting set of arguments. If > I understand your point as being, if a product is free how can one > possibly sue the maker of it for flaws in the product? Correct me if I'm > wrong. > > I have my own thoughts on this topic but I simply want to make sure what > we're discussing. > Imagine driving by a house and seeing a car in front with this sign -- "Free car." It is your responsibility to check out the car. If I were interested in that car, I'd talk to the giver of the car, check out the car for myself (is it stolen?) and then either drive it carefully to a mechanic or have a mechanic come to the car. After that I'd be the only one that rides in the car for a month or two to be more certain that it is in fact a safe car. As long as the giver reveals any known problems about the car to me, I don't think there's any basis for suing him if the car is later found to have a serious problem. Brian Wood http://webEbenezer.net (651) 251-9384
From: Andy Champ on 11 Feb 2010 16:33 Lew wrote: > > Andy Champ wrote: >> 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. > > Sure, that's why so many programs had to be re-written in 1999. > > Where do you get your conclusions? > Pretty well everything I saw back in 1982 was out of use by 1999. How much software do you know that made the transition? Let's see.. Operating systems. The PC world was... umm.. CP/M 80? Maybe MS-Dos 1.0? And by 1999 I was working on drivers for Windows 2000. That's at least two, maybe three depending how you count it, ground-up re-writes of the OS. With that almost all the PC apps had gone from 8 bit versions in 64kb of RAM to 16-bit DOS to Windows 3.1 16-bit with non-preemptive multitasking and finally to a 32-bit app with multi-threading and pre-emptive multitasking running in hundreds of megs. OK, so how about embedded stuff? That dot-matrix printer became a laserjet. The terminal concentrator lost its RS232 ports, gained a proprietary LAN, then lost that and got ethernet. And finally evaporated in a cloud of client-server computing smoke. I'm not so up on the mainframe world - but I'll be surprised if the change from dumb terminals to PC clients didn't have a pretty major effect on the software down the back. Where do you get your conclusions that there was much software out there that was worth re-writing eighteen years ahead of time? Remember to allow for compound interest on the money invested on that development... Andy.
From: Bo Persson on 11 Feb 2010 16:49 MarkusSchaber wrote: > 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. Is it? What about the software that controls the locks, cars, and airplanes? Bo Persson
From: Wojtek on 11 Feb 2010 17:17 Andy Champ wrote : > Lew wrote: >> >> Andy Champ wrote: >>> 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. >> >> Sure, that's why so many programs had to be re-written in 1999. >> >> Where do you get your conclusions? >> > > How much software do you know that made the transition? > I'm not so up on the mainframe world Yup. Made lots of money transitioning mainframe apps. -- Wojtek :-)
From: Lew on 11 Feb 2010 17:28
Andy Champ wrote: >>> 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. Lew wrote: >> Sure, that's why so many programs had to be re-written in 1999. >> >> Where do you get your conclusions? Andy Champ wrote: > Pretty well everything I saw back in 1982 was out of use by 1999. How > much software do you know that made the transition? Pretty much everything I saw back in 1982 is in production to this day, never mind 1999. Pretty much everything that had Y2K issues in 1999 was in production since the 1980s or earlier. By the 90s, more software was written without that bug. Again, why do you think Y2K was such an issue, if affected software had gone out of production by then? > Let's see.. Operating systems. The PC world was... umm.. CP/M 80? Maybe > MS-Dos 1.0? And by 1999 I was working on drivers for Windows 2000. > That's at least two, maybe three depending how you count it, ground-up > re-writes of the OS. PCs were not relevant in 1982. PCs largely didn't have Y2K issues; it was mainly a mainframe issue. > With that almost all the PC apps had gone from 8 bit versions in 64kb of > RAM to 16-bit DOS to Windows 3.1 16-bit with non-preemptive multitasking > and finally to a 32-bit app with multi-threading and pre-emptive > multitasking running in hundreds of megs. Largely irrelevant to the discussion of Y2K issues, which were a mainframe issue for the most part. PCs were not in common use in 1982. > OK, so how about embedded stuff? That dot-matrix printer became a > laserjet. The terminal concentrator lost its RS232 ports, gained a > proprietary LAN, then lost that and got ethernet. And finally > evaporated in a cloud of client-server computing smoke. Not relevant to the discussion of Y2K issues. > I'm not so up on the mainframe world - but I'll be surprised if the > change from dumb terminals to PC clients didn't have a pretty major > effect on the software down the back. This was mainframe stuff. Most PC software didn't have Y2K bugs, and there weren't PCs in common use in 1982. PCs have had negligible effect on mainframe applications, other than to provide new ways of feeding them. > Where do you get your conclusions that there was much software out there > that was worth re-writing eighteen years ahead of time? Remember to > allow for compound interest on the money invested on that development... Software development costs are inversely proportional to the fourth power of the time allotted. That's way beyond the inflation rate. Y2K repair costs were inflated by the failure to deal with them early, not reduced. The point of my example wasn't that Y2K should have been handled earlier, but that the presence of the bug was not due to developer fault but management decision, a point you ignored. -- Lew |