Motivation of software professionals
in [Java Programming]
|
From: Martin Gregorie on 12 Feb 2010 09:42 On Fri, 12 Feb 2010 05:58:07 -0800, Nick Keighley wrote: > On 12 Feb, 11:21, Michael Foukarakis <electricde...(a)gmail.com> wrote: >> > Products have passed all the >> > tests, yet still failed to meet spec in production. > > the testing was inadequate then. System test is supposed to test > compliance with the requirement. > Quite. System tests should at least be written by the designers, and preferably by the commissioning users. Module tests should NOT be written by the coders. > The System Test people do black box > testing (no access to internals) and demonstrate that it meets the > requirement. The customer then witnesses a System Acceptance Test (often > a cut-down version of System test plus some goodies of his own > (sometimes just ad hoc "what does this do then?")). > These are the only tests that really count apart from performance testing. Its really important that the project manager keep an eye on all levels of testing and especially on how the coders design unit tests or it can all turn to worms. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Patricia Shanahan on 12 Feb 2010 09:45 Martin Gregorie wrote: .... > Until CODASYL changed the language spec, some time in the mid '90s, the > only way you could get the date from the OS was with the "ACCEPT CURRENT- > DATE FROM DATE." where CURRENT-DATE could only be defined as a six digit > field: > > 01 CURRENT-DATE. > 05 CD-YY pic 99. > 05 CD-MM pic 99. > 05 CD-DD pic 99. Punch cards were another major source of date information. They had limited character sets, could not depend on elaborate preprocessing before entry, and had a hard limit of 80 characters. Even if the input record used a lot less than 80 characters, there was a strong motivation to avoid wasting characters because of the complications if future changes took a record over the limit. I first became aware of the issue in 1970, and could not get any of my fellow developers to pay any attention to it. They may have been right, because the application I was working on was written in the NCR Century assembly language, and was defunct long before 2000. Patricia
From: Lew Pitcher on 12 Feb 2010 11:52 On February 12, 2010 07:23, in comp.lang.c, martin(a)address-in-sig.invalid wrote: > On Fri, 12 Feb 2010 07:16:33 +0000, Richard Heathfield wrote: > >> 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. >> > Lets not forget that up to some time in the '90s COBOL could not read the > century, .... using it's built-in date functions ... > which created a blind spot about four digit years in many IT > people, COBOL being the language of choice for many mainframe systems > (and a lot of minicomputers too, thanks to the quality of the Microfocus > implementation). > > Until CODASYL changed the language spec, some time in the mid '90s, the > only way you could get the date from the OS .... through the COBOL language itself ... > was with the "ACCEPT CURRENT- > DATE FROM DATE." [snip] Which is why "ACCEPT CURRENT-DATE" wasn't used very much in my shop. Rather, we read current-date using an external utility module ("TDDATE") which retrieved the full current date /and time/, and even adjusted it (if required by options) for start-of-business-day (i.e. dates changed at 8AM, not at midnight). I don't doubt that many other serious COBOL shops had similar facilities. -- Lew Pitcher Master Codewright & JOAT-in-training | Registered Linux User #112576 Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/ ---------- Slackware - Because I know what I'm doing. ------
From: MarkusSchaber on 12 Feb 2010 12:35 On 11 Feb., 22:49, "Bo Persson" <b...(a)gmb.dk> wrote: > 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? As I said, only a few places. Try to find an insurance against word corrupting your PhD Thesis, and you'll understand. Markus
From: Brian on 12 Feb 2010 13:52
On Feb 12, 1:11 am, Leif Roar Moldskred <le...(a)huldreheim.homelinux.org> wrote: > In comp.lang.java.programmer Brian <c...(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. > You clipped what I wrote about revealing known problems. If I give someone a twenty dollar bill and later when they use that bill it is found to be a counterfeit, I don't think they will sue me unless they have some reason to believe I knew it was a counterfeit. Brian Wood http://webEbenezer.net (651) 251-9384 "And David longed, and said, Oh that one would give me drink of the water of the well of Bethlehem, that is at the gate!" 1 Chronicles 11:17 |