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

SkippyPB wrote:

> On Wed, 04 Aug 2004 00:09:03 GMT, robert.deletethis@wagner.net (Robert
> Wagner) enlightened us:
>
> 
>
>
> And if century is unneeded, then you have wasted two bytes.

The problem is that no one can look into the future and say "we'll never
need the century!"  Right now, there is a set of programs I recently
inherited (due to internal reorganization).  In the main record for that
subsystem, there is an "estimated delivery date" in the format YDDD.
The thought behind that was "oh, we'll never exceed 30 days or so, so
this will be fine."

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.  Well, now we have programs (both in development and
production) that are timing out because of the length of the chain it
has to walk on these records.  There are some that are over 10 years
old, and the only way we have of knowing is the date stamp in the record.

Recent analysis showed that some of these up to three years old are
accurately showing as still open (a resync between both systems
demonstrated this).  Now, I'm sure that the original designer thought
they were being "efficient", especially when this saved a whole
character per transaction.  However, they have been shown to be very
short-sighted, as their original design is now being stretched past its
limitation.

Mr. Wagner had a point a few posts back (yes, I'm way behind - found out
we're expecting #3, and life has been crazy for the last few ws) that
programmers had seemingly not learned their lesson from Y2K, and were
still trying to be "efficient" at the expense of flexibility of future
use.  All he got in response were pedantic replies, but he has a very
valid point.  In today's increasingly networked culture, there is
apparent folly by continuing to use proprietary "packed" formats (and
other such techniques) on external data stores.  I realize that existing
designs may not be able to be redesigned (as I'm still trying to figure
out a way around my single-year dilemma).  But for new development (as
indicated by Mr. Klein's analysis), instantiating this is just asking
for trouble down the road.

The key to this is how the data is exposed.  I really like the concept
of the "integer of date" format.  It seems to me to be no different from
most relational databases - they don't store the date in YYYY-MM-DD
HH:MM:SS.PPPPPP format, but they _expose_ it to the outside world that
way (or lots of different ways, depending on how you ask for it or how
you configure it).  Without hex-editing the database's files, you can't
see the date in its "native" format.  While you wouldn't dream of
sending a database repository to someone else (unless they had the exact
same version of software, but even then, it would be flaky), people
routinely try to exchange files created and maintained by COBOL programs
to people whose tools are often no more sophisticated that Notepad.

Ponder this...  A programmer decides to use display usage on a
particular file.  A few years on down the road, two mergers later, a new
manager decides they need to send that file to an external entity.  Is
the system viewed as sluggish and inefficient, or responsive and flexible?

Remember - it's true that Mr. Wagner cannot see into the future - but
neither can any of the rest of either.  For new development, in my
opinion, usage display (in files) or relational databases are the way to
go.  They provide the greatest flexibility for future (unknown)
requirements.


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com wrote:

> In article <HVvTc.15858$5s3.12357@fe40.usenetserver.com>,
> LX-i  <lxi0007@netscape.net> wrote:
>
> [snip]
>
> 
>
>
> 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?  This isn't just some mindless
suggestion, though - it's based on lessons learned throughout several
years of software design.  At least where I work (and I've heard this
taught in class as well), my job as a software developer is to read the
requirements from the user and try to decided what they are _really_
asking for.

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?  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.
 
>
>
> This was similar to a problem Mr Hamasaki found in a system that was using
> single-digit years... it blew up the first time it tried to span a decade.
>
> 
>
>
> 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."
 
>
>
> Bingo.  '... their original design is now being stretched past its
> limitation.'  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.

> A reasonable conclusion is that either you get a new car or resign
> yourself to making a lot of extra trips, in essence you redesign the
> solution to your transportation needs.  Note that this instance is not one
> of timespan but of 'system volume'... but the conclusion is the same;
> needs have changed to the point where redesign is necessary.
>
> 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.  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.
 
>
>
> Likewise, ponder this: a couple gets married and immediately buys the
> largest minivan that's on the market... after all, a few years down the
> line they might have five kids and two Dobermans to ferry about, you never
> knoooo-ooooowwww.

By the time the fifth child comes along, that vehicle will probably have
deteriorated to the point that they need to buy a new one.  However,
software isn't quite like a car.  Maybe they could pay an extra $2K up
front for their compact car, with the understanding that if/when the
time ever arose that they needed seating for 7, the seats and storage
room would be there with no additional cash outlay.  Bits don't
deteriorate, and especially with relational databases, you can carry
around extra capability without it being harder to get into a standard
parking space.

> Needs are evaluated and extrapolated... and systems are designed and
> implemented.  If you then try to fit more folks into a compact car than it
> was designed for then the results wind up looking like clowns at a circus.

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.
Software developers in 2004 have one thing that the software developers
in 1974 didn't have - an extra thirty years of industry experience.
There are several lessons that one could learn from those 30 years.

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.
As a designer/developer, I feel that I would be doing a disservice to
my employer/client if I do not apply that knowledge, and design a system
that is flexible enough to do what they initially ask of it, and maybe
just a little bit more - *especially* when it comes to dates.

An example - I was asked to design and code software to allow a golf
"association" to track its members, sign them up for a tournament, place
the people into teams, calculate handicaps, score, and calculate payouts
for top scorers for each day, top scorer within skill level (A/B/C/D),
and overall top scorer.  By adding a single foreign key to a few tables,
this application supports more than one organization in its _initial_
state.  And, with a simple tweak, if organizations ever wish to share
members, a new table (initially populated with values from the current
Members table) would do it quite quickly.

Was I asked to make a multi-organization-supporting system?  Not
initially.  After the first tournament, the customer asked me what it
would take to get other golfing organizations loaded into it.  Sounds
like I hit the nail on the head with that one.  :)  (Of course, there
was a little self-serving in that as well - I had hoped that they would
give me rights to the program, and they have.  Now, _my_ job is easier!)


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com wrote:
> In article <E95Uc.23224$5s3.1064@fe40.usenetserver.com>,
> LX-i  <lxi0007@netscape.net> wrote:
> 
>
>
> 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.  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 and a goodly bunch of the rest of the Programming World... but there
> also comes a point where one must remember that there's no DWIM (Do What I
> Mean) command.

Which makes this job such fun.  :)  I'm glad I can still keep my fingers
in the code - if I had to go straight design, I'd probably go insane.
(Granted, that probably wouldn't be much of a trip...)
 
>
>
> 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.
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.
 
>
> 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.  My current project spans a couple of things - first, the
USAF's decision to change the F-22 to an A/F-22, and second, the USN's
decision to track some stuff from the CV-22 in our system.  Right now,
our code is littered with checks like "IF MDS = '  F022A A' " or "IF MDS
= '  F0119100' " (that's the engine it uses) because they track their
parts differently from any existing aircraft in the USAF inventory.

The reason they were allowed to do this is that the regulation has
changed, and new aircraft have to follow the new standard.  Enter the
CV-22 - they use the same type of stuff as the F-22.  So, this project
entails pulling out all these checks, creating a lookup table, and
having the checks look at the table.  Now, the original F-22 design was
complete (it works, and satisfied the requirement), but it was very
short-sighted.  Quite expensive to go and make the change, but when the
Joint Strike Fighter comes along, it'll be much cheaper and much faster,
as the design is flexible enough to drop other yet-to-be-determined
aircraft into it.

(In fact, now that the "MDS" is now " AF022A A", the original code
doesn't even work.  In the new design, that's a one-row change in a
relational table - total cost to the taxpayers of this great land, $.05
(or somewhere thereabout).)
 
>
>
> 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.  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.
 
>
>
> 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?  (As an aside, we already do the multiple-trip
thing with this interface.  The packets have a maximum size of around
3,000 characters, and they send us 80-character lines even when a CR/LF
will do.  So, we sometimes get as many as 4 or 5 responses for one
transaction.

(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.)
 
>
>
> 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.  :)  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...)
 
>
>
> 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.  :)  And
besides, it only seems to be a problem for us, not them.  Why *would*
their management see it as a need?

> 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...)
 
>
>
> 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."

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...  :)
 
>
>
> 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.
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.  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."

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..."
 
>
>
> 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.
 
>
>
> Lessons like how to tailor a system to transaction volume?  that could be
> done in 1974; some might argue that given the resource-expenses of those
> days it was done better then than now.

Not those lessons - yes, looking back at software development from the
1950s on forward, it's amazing what was accomplished before the chip
speed explosion and the world wide web.  I'm not knocking older, mature
designs.  What started this whole spin-off thread was my assertion that
storing dates and numbers with Display usage in files makes the design
of the system more flexible for yet-unknown requirements.  Today, with
large, cheap disks, I have the luxury of saying that.  In 1974, I
probably would be singing a different tune.
 
>
>
> 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.

> 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."

Our relational tables have changed that concept, just because it's so
easy to add a column to one of those.  We don't use "Select *", so we
won't impact existing programs.


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

In article <HdaUc.23233$5s3.3255@fe40.usenetserver.com>,
LX-i  <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote: 
>
>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]
 
>
>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.

> 
>
>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]
 
>
>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]
 
>
>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]
 
>
>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.

> 
>
>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.)

> 
>
>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.

> 
>
>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]
 
>
>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]
 
>
>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]
 
>
>True as well.  I understand that concept.

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

> 
>
>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

docdwarf@panix.com wrote

> 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.

Perhaps you take a more recent look, they seem to have managed to
stuff another one in there somehow.

In article <217e491a.0408162302.66ba1014@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>docdwarf@panix.com wrote
> 
>
>Perhaps you take a more recent look, they seem to have managed to
>stuff another one in there somehow.

What a wonderful world it is that has new things to learn in it!  I should
apologise for my loose usage above, though; when I said 'digit' I intended
'character', as the examples I gave indicate.

DD

In article <FXxUc.24781$5s3.6269@fe40.usenetserver.com>,
LX-i  <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
> 
>
>Okay - fine.  You never knooooo-oooooooooooowwwww!  :)

Gah... that is the Appeal to Universal Ignorance.

[snip]
 
>
>No, it hasn't.  I've been told that this has been a problem for over a
>decade, and hasn't been addressed.

It might be good to remind someone that a problem that is not addressed
can be similar to a bank-account that is not addressed... it seems to
slumber but it actually gathers 'interest'.

[snip]
 
>
>heh - we'll probably end up putting a switch on a screen anyway.  The
>other option involves destruction of interface settings, which would
>then have to be remembered and reloaded by a human later on down the
>road.

Relying on a human being to know how to do something, remember when to do
something and actually do it runs perilously close to violating the Mac
Truck theory.

>What we've finally gotten is a retired CMSgt who used to use this
>system on the flightline - he understands what the user wants, and he
>also has enough experience with us as a development team that he's
>beginning to trust what we tell him.
>
>But, I know that could change in the morning...

Not as long as you keep him drunk.

> 
>
>I've come up with several solutions that weren't accepted.  In fact, one
>made it into the code baseline on accident, and then promptly died.

'I want someone who's made all the mistakes... on someone *else's* dime.'
 
>
>The problem is that these folks often aren't the same folks who made the
>earlier edict.

Ahhhh... regime change!  Watch out, next comes calendar reform.

>Today, I looked at some code that the user swore up and
>down shouldn't be spacing out a field under that condition.  But, the
>two lines that spaced out the field were clearly footprinted as being
>entered into the system in 1993, due to a duly documented requirement.

'Whaddaya mean, we asked for it ten years ago... that was ten years ago,
you can't hold us to what we said back then... and what about *this*
difficulty over here, we've been talking about that since *forever*...
whaddaya mean, 'forever' is longer than ten years so you're not going to
hold to it?'

> 
>
>That's the rub in all this.  Right now, I have a short window of
>round-tuitiveness.  By the time enough people far enough up either chain
>get riled up enough about it, I'll be up to my neck in the next project.

If someone of sufficient authority feels sufficiently strongly about your
work-assignment then it might change.

>  I was more venting than anything else (although I'd fix it in a
>heartbeat...)

Pardon me for my innate problem-solving views.

> 
>
>Ah...  Thanks.

Anytime.

[snip]
 
>
>:)  It may (although our compiler doesn't support hex literals)...

Doesn't have to... define an 8-byte binary field, REDEFINE it as a PIC X.

0000 0000 = X'00', add 1 to get
0000 0001 = X'01', add 1 to get
0000 0010 = X'02', etc.

Since you are dealing with an ASCII numeric field for your year you'd lose
everything between X'00' and X'29'... but start working with X'40' and you
have something that could be made to work for the next 215 years or so...

... but don't let that give you any ideas.

[snip]
 
>
>heh heh...

Glad you enjoyed.

> 
>
>Oh, is that it?  I guess I should add that to the list of questions to
>ask dealers when I'm shopping for a car!  ;)

That's the Common Knowledge I was taught - 'Never buy a car made on Friday
or Monday, Friday they're sloppy because they're looking to get out,
Monday they're sloppy because of hangovers' - but I do not know of
statistical data to support it.

[snip]
 
>
>heh - that's the truth.  "Add this option.  Add the other option.  Okay,
>now add these three options, and put these two as sub-options under the
>4th option."
>
>"Man, this thing just has too many options!"

See above about holding someone to what they said.

> 
>
>hey - deficit spending is !  (Especially deficit *defense* spending!)

Remind your landlord of that the next time he finds out you gave him a
Goodyear check.

[snip]
 
>
>True - but do they have 24/7 contracts on their employees, that state at
>any given time they'll willingly give their lives obeying the orders of
>their superiors?

The USAF appears to be slightly different from many other organisations in
that regard.

(small joke - there are military offices in the building which houses my
current client; today I was riding the elevator down and a lass wearing
blues and a set of railroad-tracks got on.  I looked at him and said in my
best Official Voice -

'Beg pardon, sir, but I gotta tell ya... I spent a little time at Lackland
a few decades back and... I just can't believe how young they're making
Captains nowadays.

> 
>
>I guess I'm just idealistic.  Either that, or a darn good catch for an
>employee...  :)

'An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup.' - H L Mencken

[snip]
 
>
>That's the fear amongst the managers - how long until it dies?

Behavior modification is a whole 'yuther kettle of wax.

DD

docdwarf@panix.com wrote:
> In article <FXxUc.24781$5s3.6269@fe40.usenetserver.com>,
> LX-i  <lxi0007@netscape.net> wrote:
> 
>
>
> Gah... that is the Appeal to Universal Ignorance.

Well, "ignorant" can be a fitting adjective at times - address your
audience and all that sort of thing...
 
>
> It might be good to remind someone that a problem that is not addressed
> can be similar to a bank-account that is not addressed... it seems to
> slumber but it actually gathers 'interest'.

heh - interest rates are at an all-time high!  Today we got several
field calls about document numbers (containing the aforementioned
1-digit year) that "all of a sudden" showed up on their reports.

(As an aside, I also learned that there is a resync process that's
supposed to be run once a month - but, obviously, folks don't seem to be
doing that.  This whole thing may come down to a policy issue, and not
so much a code issue (although I still need to solve the decade
expansion, or we can't do anything on December 31st every four years...))
 
>
> Relying on a human being to know how to do something, remember when to do
> something and actually do it runs perilously close to violating the Mac
> Truck theory.

true...
 
>
> Not as long as you keep him drunk.

:)  I'll pass that along to him - he'll get a kick out of that.
 
>
> 'I want someone who's made all the mistakes... on someone *else's* dime.'

I'm your guy, then.  Oh, no wait - it's _your_ taxes that pay _my_
salary.  I'm screwing up on *everybody's* dime!  (Well, except the
almost 50% of folks who don't pay any Federal income tax...)
 
>
> Ahhhh... regime change!  Watch out, next comes calendar reform.

heh - we're working on that....
 
>
> 'Whaddaya mean, we asked for it ten years ago... that was ten years ago,
> you can't hold us to what we said back then... and what about *this*
> difficulty over here, we've been talking about that since *forever*...
> whaddaya mean, 'forever' is longer than ten years so you're not going to
> hold to it?'

Well, wouldn't you know it, in looking at that, they found something
else that was actually broken.
 
>
> If someone of sufficient authority feels sufficiently strongly about your
> work-assignment then it might change.

heh - it looks like my coding dance card is going to be pretty full
through the next few months.  Today our high-level design was approved
for our next project, so we'll begin detailed design and coding shortly.
 
>
> Pardon me for my innate problem-solving views.

Oh, no problem - if I wasn't interested, I wouldn't have carried on the
conversation this long.  I do the same thing.  :)
 
>
> Doesn't have to... define an 8-byte binary field, REDEFINE it as a PIC X.
>
> 0000 0000 = X'00', add 1 to get
> 0000 0001 = X'01', add 1 to get
> 0000 0010 = X'02', etc.
>
> Since you are dealing with an ASCII numeric field for your year you'd lose
> everything between X'00' and X'29'... but start working with X'40' and you
> have something that could be made to work for the next 215 years or so...
>
> ... but don't let that give you any ideas.

heh heh - and if I make it smart enough to loop every hundred years, it
could work forever!
 
>
> That's the Common Knowledge I was taught - 'Never buy a car made on Friday
> or Monday, Friday they're sloppy because they're looking to get out,
> Monday they're sloppy because of hangovers' - but I do not know of
> statistical data to support it.

That sounds like a good science project for some bright kid.  Get a
cross-reference of VINs and day of manufacture, then bounce it against
service records from a representative sample of dealerships.  True,
you'd miss the do-it-yourselfers, but chances are you'd miss them in
equal proportions.

(Or, do it backwards - get the VINs and number of unscheduled
maintenance visits, then look up the day out of that database - it could
be fun - I'd probably give it an "A" if it followed the proper
scientific process...)
 
>
> Remind your landlord of that the next time he finds out you gave him a
> Goodyear check.

You (and the rest of the taxpayers of this great land) are paying my
rent for now, but I understand what you're talking about...  :)
 
>
> The USAF appears to be slightly different from many other organisations in
> that regard.

:)

> (small joke - there are military offices in the building which houses my
> current client; today I was riding the elevator down and a lass wearing
> blues and a set of railroad-tracks got on.  I looked at him and said in my
> best Official Voice -
>
> 'Beg pardon, sir, but I gotta tell ya... I spent a little time at Lackland
> a few decades back and... I just can't believe how young they're making
> Captains nowadays.

I thought I was the only one to notice.  Mine was when they promoted
this kid to Major - he looked like a 16-year-old kid!  Come to find out,
he's a year younger than me.  Here I am a struggling E-5, and if I had
applied myself coming out of high school, I could be an O-4 by now.
Choices, choices...

> 'An idealist is one who, on noticing that a rose smells better than a
> cabbage, concludes that it will also make better soup.' - H L Mencken

That's great.  :)


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

On 18-Aug-2004, LX-i <lxi0007@netscape.net> wrote:

> I'm your guy, then.  Oh, no wait - it's _your_ taxes that pay _my_
> salary.  I'm screwing up on *everybody's* dime!  (Well, except the
> almost 50% of folks who don't pay any Federal income tax...)

Some people don't pay Federal income tax directly.    But anybody who buys
something from a company that pays Federal income tax - is paying indirectly
.

docdwarf@panix.com wrote in message news:<cfm40m$br5$1@panix5.panix.com>...
> In article <HVvTc.15858$5s3.12357@fe40.usenetserver.com>,
> LX-i  <lxi0007@netscape.net> wrote:
 
>
> Likewise, ponder this: a couple gets married and immediately buys the
> largest minivan that's on the market... after all, a few years down the
> line they might have five kids and two Dobermans to ferry about, you never
> knoooo-ooooowwww.

Your analogy is seriously flawed, as it doesn't take the cost of
computer hardware vs. developer expense into account.  If you want
your analogy to be a better, useful representation of the issue, then
"ponder" this:  The biggest, most luxurious and _safest_ minivan they
could possibly buy cost ten cents more than the el cheapo car they
"should" be getting, and costs two bucks per year more to operate.

Now you have a quasi-valid analogy.


Curtis