Motivation of software professionals
in [Dot Net]
|
From: James Kanze on 17 Feb 2010 16:14 On Feb 16, 10:09 am, Nick Keighley <nick_keighley_nos...(a)hotmail.com> wrote: > On 16 Feb, 03:40, Seebs <usenet-nos...(a)seebs.net> wrote: > > On 2010-02-16, James Kanze <james.ka...(a)gmail.com> wrote: > > > On Feb 14, 4:56 pm, Seebs <usenet-nos...(a)seebs.net> wrote: > > >> On 2010-02-14, James Kanze <james.ka...(a)gmail.com> wrote: > > >> > To be really effective, design and code review requires a > > >> > physical meeting. Depending on the organization of the project, > > >> > such physical meetings are more or less difficult. > I've got mixed opinions on this. The real review takes place > off line. Explanation and discussion of possible solutions (I > know, a code walthru isn't supposed to consider solutions- a > daft idea if you ask me [1]) at a meeting. > Design meeetings can work. It's always difficult to find the right balance, because people do vary. What I think is certain is that you do need some time isolated, to let your ideas jell, and you need some meetings, at least at either end: brainstorming sessions before really starting, and code reviews after the code has been written. Between the two, different people probably have different needs. A lot of people claim that they're most effective in pair programming, for example, where as I (and some others I know) would be much less effective if I couldn't do large parts of the work more or less in isolation. -- James Kanze
From: Mike Schilling on 17 Feb 2010 21:01 Branimir Maksimovic wrote: > Nick Keighley wrote: >> >> I was noting the fixed point in the human experience. Things are >> degenerating and were always better in the past. >> >> <snip> > > To be honest things were always simpler in the past. Compare disks which ae formatted for a particular record size (requiring the inter-record gap to be figured into the record/track calculation) with disks that have fixed sector sizes, Which is simpler?
From: Flash Gordon on 21 Feb 2010 16:01 Richard Heathfield wrote: > Lars Enderin wrote: >> Richard Bos wrote: >>> Flash Gordon <smap(a)spam.causeway.com> wrote: >>> >>>> 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). >>> Single signed byte? >> >> Was it really 2028? > > Quite possibly. Not every problem ending in 8 is a 2038 problem. If the > test rigs had 1900 as a base date (and yes, there's still plenty of > software around that thinks 1900 was a very good year), then the single > signed byte Richard Bos mentioned would be good for representing all > years from then until 2027 (assuming 8 bits to the byte). It would fail > in 2028, quite possibly giving the year as 1772 instead. It was indeed 2028 when it fell over. I can't remember all of the exact details, but it was the HP Pascal system, which was based on UCSD (IIRC). I think the data structure was either defined as being 0..99 or 0..127, and it definitely hit a problem when it rolled over to 2028, but I can't remember the exact details and don't have access to the systems any more (I work for a different company). I suspect it could have been the date encoded in to a 16 bit word as 7 bits - year 4 bits - month 5 bits - day I did clearly document the date of failure when I was asked to look in to Y2K, but of course that documentation will be lost before then! I also documented that the simple work-around would be to set the date wrong and just write on the printouts the correct date! -- Flash Gordon
From: John B. Matthews on 21 Feb 2010 19:56 In article <qij857xp3j.ln2(a)news.flash-gordon.me.uk>, Flash Gordon <smap(a)spam.causeway.com> wrote: [...] > It was indeed 2028 when it fell over. I can't remember all of the > exact details, but it was the HP Pascal system, which was based on > UCSD (IIRC). I think the data structure was either defined as being > 0..99 or 0..127, and it definitely hit a problem when it rolled over > to 2028, but I can't remember the exact details and don't have access > to the systems any more (I work for a different company). > > I suspect it could have been the date encoded in to a 16 bit word as > 7 bits - year > 4 bits - month > 5 bits - day > > I did clearly document the date of failure when I was asked to look > in to Y2K, but of course that documentation will be lost before then! > I also documented that the simple work-around would be to set the > date wrong and just write on the printouts the correct date! For reference, UCDSD Pascal I.5/II.0/III.0: daterec = packed record month: 0..12; { 0 IMPLIES DATE NOT MEANINGFUL } day: 0..31; { DAY OF MONTH } year: 0..100 { 100 IS TEMP DISK FLAG } end { DATEREC } ; <http://invent.ucsd.edu/technology/cases/1995-prior/SD1991-807.shtml> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Flash Gordon on 23 Feb 2010 19:22
John B. Matthews wrote: > In article <qij857xp3j.ln2(a)news.flash-gordon.me.uk>, > Flash Gordon <smap(a)spam.causeway.com> wrote: > > [...] >> It was indeed 2028 when it fell over. I can't remember all of the >> exact details, but it was the HP Pascal system, which was based on >> UCSD (IIRC). I think the data structure was either defined as being >> 0..99 or 0..127, and it definitely hit a problem when it rolled over >> to 2028, but I can't remember the exact details and don't have access >> to the systems any more (I work for a different company). >> >> I suspect it could have been the date encoded in to a 16 bit word as >> 7 bits - year >> 4 bits - month >> 5 bits - day >> >> I did clearly document the date of failure when I was asked to look >> in to Y2K, but of course that documentation will be lost before then! >> I also documented that the simple work-around would be to set the >> date wrong and just write on the printouts the correct date! > > For reference, UCDSD Pascal I.5/II.0/III.0: > > daterec = packed record > month: 0..12; { 0 IMPLIES DATE NOT MEANINGFUL } > day: 0..31; { DAY OF MONTH } > year: 0..100 { 100 IS TEMP DISK FLAG } > end { DATEREC } ; > > <http://invent.ucsd.edu/technology/cases/1995-prior/SD1991-807.shtml> Then I was probably right :-) Actually, that does sound familiar, apart from the comment about 100. I know I did active testing, including setting the time to before midnight, doing power cycles after 2000 (makes sure it did not change on power up) etc. I think there might have been some display issues outside the application which we did not care about. So it just goes to show, we've still got the 2028 problem to deal with! Perhaps I should brush up on my Pascal! -- Flash Gordon |