Re: The Great Date Debate [Was Re: Layout Hell-o]

docdwarf_at_panix.com
Date: 08/17/04

  • Next message: Richard: "Re: The Great Date Debate [Was Re: Layout Hell-o]" 
    Date: 16 Aug 2004 19:48:31 -0400

    In article <HdaUc.23233$5s3.3255@fe40.usenetserver.com>,
    LX-i <lxi0007@netscape.net> wrote:
    >docdwarf@panix.com wrote:
    >> In article <E95Uc.23224$5s3.1064@fe40.usenetserver.com>,
    >> LX-i <lxi0007@netscape.net> wrote:
    >>
    >>>docdwarf@panix.com wrote:
    >>>
    >>>
    >>>>In article <HVvTc.15858$5s3.12357@fe40.usenetserver.com>,
    >>>>LX-i <lxi0007@netscape.net> wrote:
    >>>>
    >>>>[snip]
    >>>>
    >>>>
    >>>>
    >>>>>The problem is that no one can look into the future and say "we'll never
    >>>>>need the century!"
    >>>>
    >>>>
    >>>>Gah... this is a variant of the Appeal to Universal Ignorance, usually
    >>>>mainfested as a crooned 'you never knoooo-oooooowwww!'.
    >>>
    >>>Does that in any way change its truth?
    >>
    >>
    >> There is no way that truth or falsity can be determined... after all, 'you
    >> never knoooo-oooooowwww!'
    >>
    >> (Now you may see why I go 'Gah...'; Wittgenstein once said 'I do not know
    >> that I do not know' and, likewise, you never know that you never
    >> knoooo-oooooowwww!)
    >
    >But you can make an educated guess.

    You can guess, sure... but you never knoooo-oooooowwww!

    >Is it smart to make all your dates
    >also have an associated time, down to 18 digits of precision? Probably
    >not. Is it a good idea to store off four digits for a year? In my
    >opinion, that answer is yes. If you answer no (and have a
    >requirements-based reason for answering no), you don't have a faulty
    >design - you just have an inflexible one.

    You have a design for a system that runs in production, keeping users (and
    maintenance-programmers before you) happy for a decade and a half... not
    half shabby, neh?

    [snip]

    >>>I recently reviewed a requirement for a "switch" for an interface. I
    >>>asked the question - just because we have a switch for another
    >>>interface, does that mean we need one for this one?
    >>
    >>
    >> Hee hee hee... you had to ask? Frequently the 'requirements' are
    >> generated for two reasons:
    >>
    >> A) 'They got one, now we want one, too!'
    >>
    >> B) 'Something like this did... *something* over there, and now everybody's
    >> talking about it... so maybe it'll do... *something* over here, too!'
    >
    >Well, I suspected it to be along the lines of "A", and I was correct.

    I've never seen the inside of your shop and I listed 'A' as 'A'... but
    that might be due to the fact that I have worked in a few shops, here and
    there... and in each one of them 'Things Are Different Here'...

    ... and if everywhere things are different then everywhere things are the
    same.

    >However, the interfacing system has the potential to process classified
    >information; our is unclassified. So, the requirement exists to "turn
    >the interface on and off" - but we did get them to agree to let us make
    >the decision on exactly how (the behind the scenes part) we would do that.

    How very kind of them... looks like you got away with doing this one Right
    but it might be best to try not to get any feelings of security about the
    situation.

    >
    >>>I was told, in
    >>>effect, to shut up and color, but it's my job to completely understand a
    >>>requirement, so I can provide a system that is responsive to their
    >>>current needs, and flexible for perceived future needs.
    >>
    >> With all due respect... is that in your job spec or a responsibility
    >> you've taken upon yourself?
    >
    >Thanks... :) And, it's not in a written description, but it's expected
    >of each of us.

    Hee hee hee... it is only expected when the results you come up with are
    expected; when you come up with unexpected solutions the reception might
    be a bit... chillier.

    [snip]

    >>>>>Well, this record in involved in an interface with another system, which
    >>>>>has proven to be less than 100%. In fact, the reason it wasn't expanded
    >>>>>with the rest of the Y2K stuff is that the interfacing system didn't see
    >>>>>the need to do it.
    >>>>
    >>>>
    >>>>Gah... systems do not see needs, *people* do.
    >>>
    >>>Okay - "the user community for the interfacing system didn't see the
    >>>need to change their system."
    >>
    >>
    >> Ahhhhhh, that's better... now, reconcile the above with the Workplace
    >> Truism of 'A lack of planning and foresight on your part does not
    >> constitute an emergency on my part.'
    >
    >Okay - but for some reason, the chain of command doesn't like hearing
    >that sort of stuff.

    It has been my experience that most folks who lack planning and foresight
    don't like hearing that sort of stuff... might be Human Nature, who knows?

    >Their users complain when the program times out,
    >and it's our fault because we *still* haven't fixed it, yet we can't get
    >the interfacing system's managers to make the change. I can't believe
    >it would be _that_ complicated of a change - they're in the same
    >environment our system is in.

    It might be due to the fact that the task is of insufficient importance to
    merit it's own job code and budget... and it lacks those because someone
    without planning and foresight (but with control over budget) has not
    allocated such things.

    If it is important it is more likely that someone will spend a buck on
    it... if it isn't important, if a raise or a promotion isn't depending on
    it then one waits until one is issued a Round Too-it.

    [snip]

    >>>>Consider: two people get married and buy a compact car;
    >>>>this carries them fine. Next a child comes along, the car can still carry
    >>>>them and their groceries... no sweat. Then comes along another child...
    >>>>what might seem to be a reasonable conclusion?
    >>>
    >>>Either buy a bigger vehicle (sedan, mini-van, SUV, etc.), or rent a
    >>>larger vehicle for times when they need more space.
    >>
    >>
    >> Oooooo... *someone's* been reading ahead!
    >
    >heh - yes, I read ahead, but this intrigues me (and you didn't address
    >it). What is the parallel for "renting a larger vehicle" in the
    >software design world?

    Outsourcing your processing or buying time-shared resources.

    [snip]

    >(Yes, I asked to inherit this interface - I'm making it my goal to
    >streamline it and make it more usable. There are programs that people
    >in the field have stopped using because they just don't work.)

    Not a bad reason to stop using them, aye.

    [snip]

    >>>>The original system's design might have exceeded the original system's
    >>>>requirements; it is not the original system's fault that someone decided
    >>>>to try to accomodate the needs of a multi-child family with a compact car.
    >>>
    >>>Right. But it is _my_ fault if I don't learn from that, and make my
    >>>designs for future systems more accommodating.
    >>
    >>
    >> Again, with all due respect... I do not believe that you needed to learn
    >> that single-digit years are more trouble than their systemwide savings
    >> appear to merit.
    >
    >Thanks again.... What I learned was not that, per se - it merely added
    >to something that I've been learning since I figured enough out about
    >this business to do design. Our systems are routinely asked to stretch
    >themselves past the point of their original requirement. :)

    Hmmmmm... that's like the classic 'I always give 110%, all the time!'...
    but if you do it all the time then 110% becomes 100%.

    >Now, for
    >this particular case, a second digit would help us immensely. But, it
    >would still violate the standard that we have in every other place in
    >our database of storing a 4-digit year.
    >
    >(What I also learned is that I have an opportunity to be really creative
    >and come up with a self-sliding 4-year window. I think I'll probably do
    >something using a 2-digit signed number...)

    Ummmmm... last time I looked a single digit can hold any one of 255
    distinct values, X'00' through X'FF'... but don't let that give you any
    ideas.

    >
    >>>And, although it's not
    >>>the other system's "fault" per se, I still believe I'm justified in
    >>>calling the design short-sighted. I can't believe they didn't have
    >>>problems with this during the 1989/1990 rollover or the 1999/2000
    >>>rollover. The fact is, they did, but no one (on their end) saw it as a
    >>>big enough deal to justify a software change.
    >>
    >>
    >> There, you see? I was wrong, single-year digits do *not* generate more
    >> problems than their systemwide appear to merit... because this system went
    >> through two rollovers and is still ticking. Why was it not changed
    >> fifteen years back? In classic Managerspeak:
    >>
    >> 'Because it isn't worth the time to put into it, we have More Important
    >> things to deal with.'
    >>
    >> ... and for what reason was it not changed five years back? See above.
    >
    >Just because the system didn't puke (well, it did - that's what brought
    >this to our attention) doesn't mean it isn't crappy design. :)

    IF PROGRAM-RUNS PERFORM NEXT-ASSIGNMENT
        ELSE PERFORM CODE-LIKE-HELL UNTIL DAMNED-THING-WORKS.

    If it runs and gives the results that make the person who has say over
    signing checks for the system smile... then it runs.

    >And
    >besides, it only seems to be a problem for us, not them. Why *would*
    >their management see it as a need?

    There is no 'us', there is no 'them'... there is no 'I' in 'team',
    remember? We're all in this together and if one of us has a problem then
    *all* of us have a problem.

    (You want to see a Major turn red and shoot eye-daggers at you then feed
    him this same kind of crap that he feeds you.)

    >
    >> Really? Consider the possibility of a couple of 'Irish twins', born nine
    >> months apart... and a set of 'genuine' twins and you've got five kids in
    >> five years. My current vehicle is eight years old and has 280K miles and
    >> change on it, the one I had before that I kept for a decade and it had
    >> 200+K miles on it... cars don't wear out like they used to, you can go
    >> (according to advertisements) 100K miles before a tune-up.
    >
    >heh - not with Montgomery drivers... ;) But yes, you are correct,
    >_some_ cars do seem to last longer than they used to. (Last December, I
    >got stuck on the side of I-85 in my 1999 Grand Voyager with a dead
    >engine - well under 90K miles...)

    Sometimes a car's made on Friday, aye.

    >
    >>>However,
    >>>software isn't quite like a car.
    >>
    >>
    >> In that it is designed to ofer maximal performance at or below a given
    >> volume it is *very* much like a car.
    >
    >Yes, but everything in a car is tangible. People don't expect their car
    >to have a pop-up calendar from which they can select dates, but they are
    >happy with the little sticker that JiffyLube puts on their windshield
    >reminding them when their next oil change is due, or the "time for a
    >tune-up" light that turns from green to yellow to red (on Hondas).
    >
    >But, give someone a web page with a required date input field, and
    >people all of a sudden can't type 2004-08-16 (or 8/16/2004, or
    >16/8/2004) - "I've got to have a pop-up box where I click a block, and
    >it fills in the date for me."

    This seems to be a sort of 'Prelude to Feature Bloat'... 'Well, it's all
    right, but I *really* need this... well, now it's OK, but I really need
    *that*... it looks pretty good but I really need *the other thing*...
    wow, this is really complex, can't you simplify it somehow?'

    >
    >Of course, talking about a car, there are those who attempt to push cars
    >beyond their designed limits - you usually hear about them on the news,
    >though. Not the same with software... :)

    There are organisations that try to push software beyond limits... and you
    read about them in the Finance Pages, going belly-up or being taken over.

    [snip]

    >> Systems have associated costs of operation and design-parameters which are
    >> predicated on transaction volume. The kind of system an
    >> accoutant-down-the-street could use, profitably and happily, would be
    >> incapable of handling the sort of volume that even the smallest of the Big
    >> 8... errrr, 5... errrr, 3 deal with.
    >>
    >> The Big 3 don't use systems designed for one-person accounting shops...
    >> and one-person accounting shops don't need the overhead associated with a
    >> Big 3 office's code.
    >
    >True. I guess that's where "knowing your customer" is very important.

    I disagree. Knowing the job to be done is very important; whenever I get
    ask about system design my *first* question is:

    I think it can be done... but tell me, what's your expected transaction
    volume?

    >As a USAF member, the USAF's interest in my work is making sure I
    >produce the longest-lasting, flexible, yet efficient, accurate, and
    >stable software I can.

    The USAF appears to be no different from any other organisation in this
    regard.

    >Now, a contractor may say something along the
    >lines of "well, this is what they asked for - I think they may need this
    >too, but I'll just do this really well and maybe I'll get the contract
    >when they figure out that they need this too."

    ... or an employee can say 'Hey, I'll get away with this for now... and by
    the time it's discovered I'll be promoted/transferred and it'll be someone
    else's headache'. Neither is unique.

    >
    >I don't have that luxury. In fact, I've been asked a few times why I've
    >done things a certain way, and had to explain myself. The answers I
    >gave that delivered the least satisfaction are the ones that start with
    >"well, I was told to..."

    Hee hee hee... when you conform to my orders how *dare* you invoke the
    Nuremberg Defense?

    [snip]

    >>>If you see software design as having to be as rigid as the physical
    >>>constraints of a vehicle, then I can see how you would feel that way.
    >>
    >>
    >> If there are not such constraints then the same software that single
    >> accountant uses would work most happily for one of the Big 3. It doesn't.
    >> You might want to speak with Mr Trembley about designing systems for
    >> utterly staggering quantities of data; try pushing a hundred million
    >> transactions through your Pentium and see if it bogs.
    >
    >Heck, my Athlon locks up with Folding@home... :) We're looking a
    >2M/day (which, I realize, is small potatoes compared with some other
    >systems), which is more than we've ever thrown at the base-level version
    >of the system.

    Has anyone thought about renting some equipment - or some time on other
    equipment - and running some heavy-volume testing to see what will bring
    it to its knees? Naaaaaahhhhh... that Costs Money!

    ('But bringing the system to a standstill due to unexpected responses to
    unprecedented volume will Cost Money, too!' 'You ain't paid to think,
    soldier... just Make It Work.')

    [snip]

    >>>One of the biggest lessons, in my opinion, is that systems are often
    >>>asked to do things well outside of the narrow scope of their original
    >>>requirements. Part of this is due to a lack of understanding between
    >>>the system procurers and the designers (often traced back to unclear
    >>>requirements). Part of it is also due to people using automated systems
    >>>and beginning to visualize other ways the system could meet their needs.
    >>
    >>
    >> Perfectly understood... bu there comes a point when redesign is necessary.
    >> Remember the auto example... a subcompact is fine for a couple, a couple
    >> and a kid, maybe even a couple and two kids... but there comes a point
    >> where a subcompact just won't do.
    >
    >True as well. I understand that concept.

    Understanding's the first step... applying what was learned the next.

    >
    >> As my first programming instructor asked the class, Zen-like:
    >>
    >> 'What is the first thing a programmer does when given an 80-byte record?'
    >>
    >> (pause for reflection and wrong answers)
    >>
    >> 'Reserve the last ten characters For Future Use.'
    >>
    >> ... and that will, truly, Hold The Fort... until more data are needed...
    >> or seen as being needed.
    >
    >In every one of our network records, we have a "spare" field. Part of
    >that is to pad it out to an even word boundary (4 ASCII character, on
    >the Unisys 2200), but part of it is for future use. My supervisor is in
    >charge of maintaining the requirements for every single field in the
    >database (quite an impressive little folder he's accumulated over the
    >years), and when a character or two from the spare field becomes pressed
    >into service, he documents it. Next major release, we name all the
    >spare usage fields, change the (hopefully few) programs that use it,
    >then reallocate spares, again, "for future use."

    As the Germans say, 'plus ca change, plus c'est la meme chose'.

    DD

  • Next message: Richard: "Re: The Great Date Debate [Was Re: Layout Hell-o]"

    Relevant Pages