Re: the gain-maximizing flaw

["Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>]

>>>>> "Roberto" == Roberto Verzola <rverzola@phil.gn.apc.org> writes:
    Roberto> In large software systems perhaps. But in controllers and
    Roberto> embedded systems, maximizing ROM- and RAM-space remained an
    Roberto> important consideration in the 80s. Even with the PIC
    Roberto> microcontrollers of the 90s, the limited memory space available
    Roberto> makes space savings a significant issue, and this can still
    Roberto> tempt a programmer to maximize space by using 2-digit year
    Roberto> fields.

  Bigger controllers are available, and have been available for some
time. This is *CLEARLY* a case of gain-maximization. It is also called
making engineering tradeoffs. They are not made in isolation: they
emerge from a business plan.

  Further, if only two bytes are available, then store it in binary.
That way you get 64k years. If one byte is available, you can store
year since 1900 (or better 1980) and get it useful until 2156 or 2236.
If you have so little CPU that you can't afford to do binary to
decimal conversion, then you reconsider having year in the system at
all.

  So, I don't even think you should "hedge" you point at all here.

    Roberto> Paul Swann just posted an account of how the Pentagon set the
    Roberto> standards (2-digit year) for DOD projects, and big business had
    Roberto> to follow suit. The DOD wanted more "bang for the buck", and I
    Roberto> would presume that big business conformed because they wanted
    Roberto> those DOD contracts.

  I would be interested in seeing copies of these documents posted
somewhere.

    Roberto> The alternative I propose is to tilt the balance back in favor
    Roberto> of risk-avoidance (and risk-minimization, for those who care to
    Roberto> apply their computational prowess) in our own rulesets, and not
    Roberto> to let the pure gain-maximizers to rule our lives.

  I think this is a definitely important thing.

    Roberto> Perhaps you can appreciate the gain-max. vs risk-min. debate
    Roberto> better if I restate it as a debate between efficiency and
    Roberto> reliability, which you must admit is a recurrent debate among
    Roberto> programmers/systems designers.  You must have your own stories
    Roberto> to tell about how some programmers just love to write
    Roberto> "efficient" routines using all kinds of tricks and
    Roberto> short-cuts. (Alan Greenspan -- now chair of the Federal Reserve
    Roberto> -- apparently was such a programmer, according to the article
    Roberto> posted by Paul Swann.) And you must know how the debate has been
    Roberto> generally settled. In instances where the debate is settled in
    Roberto> favor of efficiency rather than reliability, the result is often
    Roberto> a buggy, unreliable and crash-prone system. The Millennium Bug,
    Roberto> of course, is the most spectacular example.

  There are actually three axes, or rather, two versions "efficiency".
    Speed of execution of program (traditional efficiency)
    Reliability
    Speed of creation of program (programmer efficiency)

  If you have ever used any commodity operating systems+word processor
on a 300Mhz, 128Mb Pentium, wondered why it is slower than your
Mac/Amiga/Sun3 of the 1985 era, and then seen it "blue screen" when
you do something "complicated" then you have observed which is the
most important of the three axises.

   :!mcr!:            |  Network and security consulting/contract programming
   Michael Richardson |         Firewalls, TCP/IP and Unix administration
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
 Corporate: http://www.sandelman.ottawa.on.ca/SSW/
	ON HUMILITY: To err is human, to moo bovine.