Motivation of software professionals
in [Dot Net]
|
From: Flash Gordon on 11 Feb 2010 18:49 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? >> > > Pretty well everything I saw back in 1982 was out of use by 1999. How > much software do you know that made the transition? <snip> > 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 know there is software flying around today that is running on Z80 processors (well, the military variant of them) and the plan in the late 90s was for it to continue for another 20 years (I don't know the details, but a customer signed off on some form of ongoing support contract). Admittedly the software I used was not doing date processing (apart from the test rigs, which used the date on printouts, which I tested to "destruction" which turned out to be 2028). So yes, software from the 80s is still in active use today in the embedded world and planned to be in use for a long time to come. > 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... Remember to allow for the fact that software does continue to be used for a *long* time in some industries. -- Flash Gordon
From: Leif Roar Moldskred on 12 Feb 2010 01:53 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." -- Leif Roar Moldskred
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: 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 |