Why new calculators will be not as good as old ones?... - Hewlett Packard

This is a discussion on Why new calculators will be not as good as old ones?... - Hewlett Packard ; There was discussion about "old HP vs. new HP" calculators in terms of their quality. I promised reference to text explaining this in details. Here it is: Book "Made to Break: Technology and Obsolescence in America", by Giles Slade, Harvard ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

Thread: Why new calculators will be not as good as old ones?...

  1. Why new calculators will be not as good as old ones?...

    There was discussion about "old HP vs. new HP" calculators in terms of
    their quality. I promised reference to text explaining this in
    details. Here it is:

    Book "Made to Break: Technology and Obsolescence in America", by Giles
    Slade, Harvard University Press, 2006.

    This is not anecdotal, joke, humor or such. This is the product of
    scientific research.

    Main thesis: It has no sense to manufacture high quality products. It
    has sense to manufacture products that will break after their DESIGNED
    lifetime, and actually, designing products this way is rather hard.

    It has no sense to design calculator that will last 25 years - changes
    in technology will make it obsolete pretty quickly.

    Interesting reading. Especially for engineers.

    A.L.

  2. Re: Why new calculators will be not as good as old ones?...

    "A.L." wrote in message
    news:19pcb31f4vhrndst4949edtsghgkquk76i@4ax.com...
    > It has no sense to design calculator that will last 25 years - changes
    > in technology will make it obsolete pretty quickly.


    Agreed, but if you look at the complaints about the 35s, most of them are
    about the *software* and not so much the hardware. Just because things are
    "made to break" doesn't imply they also need to be "made to be buggy."



  3. Re: Why new calculators will be not as good as old ones?...

    On Sun, 5 Aug 2007 18:42:12 -0700, "Joel Kolstad"
    wrote:

    >"A.L." wrote in message
    >news:19pcb31f4vhrndst4949edtsghgkquk76i@4ax.com...
    >> It has no sense to design calculator that will last 25 years - changes
    >> in technology will make it obsolete pretty quickly.

    >
    >Agreed, but if you look at the complaints about the 35s, most of them are
    >about the *software* and not so much the hardware. Just because things are
    >"made to break" doesn't imply they also need to be "made to be buggy."
    >


    Yes, it does.

    In software busienss there is similar theory named "software good
    enough". This theory (absolutely serious) claims that it is reasonable
    to fix bugs until some linit. If this limit is reached, software is
    "good enough". Further improvement has no sense.

    Introduction to this philosophy can be found in following book: "Rise
    & Resurrection of the American Programmer" by Edward Yourdon, Prentice
    Hall, 1997. A lot of research papers were published in CACM and other
    journals.

    Googling on "good enough software" brings 150 million links.

    A.L.

  4. Re: Why new calculators will be not as good as old ones?...

    On Sun, 05 Aug 2007 20:48:18 -0500, "John H Meyers"
    wrote:

    >
    >There's a need for all levels of all kinds of products,
    >some which are disposable, and some which should last a lifetime
    >(or where "a lifetime" may even be determined by how long they last),
    >and it would be good if the general economy does not
    >become so narrow-minded that the range available
    >is not as wide as would best serve the whole of society.


    Agree. And it seems that it has no sense to manufacture calculators,
    PCs, 5 inch diskette drives, glass computer monitors with 25 years
    life span.

    And the question is what the PUBLIC wants: a) HP 35 now, for 50 bucks,
    or HP 35 3 years from now and for 500 bucks, with, maybe, better Enter
    key, better key click and no COS error?...

    A.L.

  5. Re: Why new calculators will be not as good as old ones?...

    "A.L." wrote in message
    news:q51db35c53scu291r68bfm34i97u4hpure@4ax.com...
    > Yes, it does. [references deleted]


    Uggh. OK, you've convinced me that plenty of people really do believe that.
    Oh well... I guess that since a business can clearly choose the type of
    managers and employees to hire, it does then just reflect on HP's corporate
    priorities today.

    In *my* opinion, any and all BUGS should be fixed. But this might be a
    semantics game: To me, software behavior that is not what the programmer
    desired is clearly a bug and should be fixed. On the other hand, behavior
    that might be "unexpected" but no one had apriori considered the "correct"
    behavior is somewhat more subjective -- maybe it's a bug, maybe it isn't.

    The cosine problem is very clearly a bug IMO, no ifs, ands, or buts about it.
    It's been documented for years, and is very easily fixed.

    I agree with a lot of what Bartosz Milewski has to say in, "C++ In Action:
    Industrial Strength Programming Techniques." One of his tenants is that by
    having a well-defined development process with clear goals of what you're
    trying to do and what your inputs and outputs aren't and a good command of the
    programming language you're using, one can eliminate many a bug that would
    otherwise creep into the code. Doing so is generally not significantly harder
    or slower than not doing so (in many cases it's easier and faster!), but it
    does require programmers WHO GIVE A DAMN. That, in my opinion, is one of the
    more difficult traits to find in employees today.

    The HP 35s is a good machine, and I have no regrets about buying one. The
    fact that its quality leaves something to be desired is, for me, more
    disappointing that anything else. I wouldn't hesitate to recommend one to a
    friend, since I very much doubt that my not doing so would significantly
    influence HP to conduct their development differently.

    ---Joel



  6. Re: Why new calculators will be not as good as old ones?...

    On Sun, 05 Aug 2007 20:42:12 -0500, Joel Kolstad wrote:

    > if you look at the complaints about the 35s, most of them are
    > about the *software* and not so much the hardware. Just because things are
    > "made to break" doesn't imply they also need to be "made to be buggy."


    When it's old technology (how to compute a trig function),
    and when one has already seen the same problem solved
    and done right, in non-secret code, explained for posterity
    in journals and in books, and in products of one's own company,
    one can wonder about re-making the same old mistakes
    (or letting the OEM make the same mistake, if that's the case).

    Perhaps part of the "planned obsolescence" market model, where
    you need to keep buying replacements to get bug-free version,
    plus sometimes a little extra improvement thrown in,
    like anniversary logo or serial port,
    to assuage the angry early-adopter

    The "flash ROM update" model was good for consumer,
    even allowing manufacturer to justify early, buggy release,
    with promise of update to come, but what happens if viewed
    as a repeat sales killer? Maybe the only way
    to compensate for the lost repeat sales
    was to make the keys fall off the 49G+

    If no "updateable" flash, then one expects better job
    before finally releasing product, no?

    At NASA and military, watch-word was once "zero defects,"
    now just "good enough" -- like quality of civilian politicians;
    same for accepting number of deaths, "collateral damage,"
    "few bad apples" killing/raping occupied country, etc.

    It's like other fashions -- after some plane crashes,
    some drug disasters, some building disasters, then FAA, FDA,
    or building codes get established, then whittled away,
    compete on price alone, take more risks until another disaster,
    then repeat the cycle, swinging between extremes.

    I left out a major factor -- consumer base has to be willing
    to pay for what it gets, not automatically go by price alone.

    There's a "curve" in which marginal effort pays off well
    in quality, until attempting to hit absolute perfection;
    we certainly know when someone has stopped at a low point on that curve,
    and ought not to be so cheapskate as to keep encouraging it,
    by rewarding Wal-Mart for squeezing producers out of any margin
    for better quality product.

    In totality, society as a whole produces what it consumes,
    so it gives itself what it wants to give, often forgetting
    that it wears both hats at once, as both consumer and producer,
    always desiring contradictory values at the same time.

    By the way, whatever happened to "idealism,"
    something beyond pure calculated economics, the "dismal science"?

    It is an intangible part of our spirit,
    and we lose something when we dismiss it,
    especially when we don't value it in ourselves.

    http://en.wikipedia.org/wiki/Dismal_Science

    -[ ]-

  7. Re: Why new calculators will be not as good as old ones?...

    On Aug 5, 10:54 pm, "John H Meyers" wrote:
    > At NASA and military, watch-word was once "zero defects,"
    > now just "good enough" --


    There is a big difference between government and military products and
    consumer products. There was a time when they all were intended to
    have "zero defects", but consumer products adopted the idea of "good
    enough until the guarantee expires" long ago.

    The idea being the one in the new Stride gum commercials. If you build
    a product that never fails, no one will ever need to buy another one!


  8. Re: Why new calculators will be not as good as old ones?...

    On Sun, 5 Aug 2007 20:56:33 -0700, "Joel Kolstad"
    wrote:

    >"A.L." wrote in message
    >news:q51db35c53scu291r68bfm34i97u4hpure@4ax.com...
    >> Yes, it does. [references deleted]

    >
    >Uggh. OK, you've convinced me that plenty of people really do believe that.
    >Oh well... I guess that since a business can clearly choose the type of
    >managers and employees to hire, it does then just reflect on HP's corporate
    >priorities today.
    >
    >In *my* opinion, any and all BUGS should be fixed.


    First, there is no way to find ALL bugs. Thesting can show only
    presence of bugs, but not absence of bugs.

    Second, the cost of bug fixing grows exponentially with the number of
    bugs fixed. Cause is that fixinb bugs injects new bugs,

    Third: There are many attempts to produce software that have no bugs,
    and this is in "mission critical systems". Control software of Boeing
    777 should have no bugs, similarly Space Shuttle. But despite all
    effors, bugs are there are are found from time to time.

    A.L.

    P.S. By the way, "software good enough" is common industrial practice
    now.

  9. Re: Why new calculators will be not as good as old ones?...

    On Sun, 05 Aug 2007 23:14:17 -0700, netsez wrote:

    >On Aug 5, 10:54 pm, "John H Meyers" wrote:
    >> At NASA and military, watch-word was once "zero defects,"
    >> now just "good enough" --

    >
    >There is a big difference between government and military products and
    >consumer products. There was a time when they all were intended to
    >have "zero defects", but consumer products adopted the idea of "good
    >enough until the guarantee expires" long ago.
    >
    >The idea being the one in the new Stride gum commercials. If you build
    >a product that never fails, no one will ever need to buy another one!


    This is the reason why service cost is so high. If your DVD player is
    broken and is not on warranty, just opening the box and making
    diagnosis costs $150. New player costs fraction of this.

    A.L.

  10. Re: Why new calculators will be not as good as old ones?...

    On Mon, 06 Aug 2007 07:02:46 -0500:

    > fixing bugs injects new bugs


    Not bugs I've fixed

    Bad design sets the stage for "difficult to maintain/modify";
    good design, vision, perspective, and deep awareness
    possessed by the minds that design things (and maintain them)
    can yield far greater reliability.

    Human awareness is at the heart of matters.

    The outstanding and insightful lecture transcript that I wanted to referto
    http://www.me.gatech.edu/news_events...ved/wtr97..htm
    http://technique.library.gatech.edu/...campus3-s.html
    http://www.me.gatech.edu/me/publicat/AugTranscript.htm [broken link]

    has now been replaced by nothing but a photograph of the lecturer
    http://www.me.gatech.edu/me/photos/GWWlecture/
    http://www.me.gatech.edu/me/photos/GWWlecture/1996.html

    And that's how the medium is replacing the message

    But there's still one savior:
    (attention to the section "No change is a small change")
    http://web.archive.org/web/199707052...Transcript.htm

    Additional comments:
    http://groups.google.com/group/comp....1?dmode=source

    -[ ]-

  11. Re: Why new calculators will be not as good as old ones?...

    On Mon, 06 Aug 2007 07:53:10 -0500, "John H Meyers"
    wrote:

    >On Mon, 06 Aug 2007 07:02:46 -0500:
    >
    >> fixing bugs injects new bugs

    >
    >Not bugs I've fixed
    >
    >Bad design sets the stage for "difficult to maintain/modify";
    >good design, vision, perspective, and deep awareness
    >possessed by the minds that design things (and maintain them)
    >can yield far greater reliability.
    >
    >Human awareness is at the heart of matters.


    There are new "hot" methodologies - Extreme programming, Agile
    Programming and such. The mantras are a) code first, think later, b)
    design is waste of time, c) no documentation are needed - code is the
    best documentation, d) client has no clue what he wants - the best
    approach is to ignore him

    A.L.

  12. Re: Why new calculators will be not as good as old ones?...

    On Mon, 06 Aug 2007 07:05:51 -0500:

    > This is the reason why service cost is so high. If your DVD player
    > is broken and is not on warranty, just opening the box and making
    > diagnosis costs $150. New player costs fraction of this.


    What about player that doesn't break, or at least lasts much longer?

    What about extra cost to consumer (and society) for "throw away" products
    that have to be bought again and again (and disposed trash dealt with),
    as in the old Volvo ad:

    [USA guy, polishing his American car]
    "This is a great car."
    "I mean, a _really_ great car."
    "If it weren't such a great car,
    why would I buy so many of them?"

    [Announcer's voice-over]
    "In Sweden, where Volvo is made,
    nine out of ten cars we ever made
    are still on the road."


    When the uncounted, long-term expenses are added in,
    some cost savings vanish, like the cost (or even impossibility)
    to repair land ruined by cheap mining or toxic waste,
    the loss of forest cut away for one-time use paper plates,
    oil reservoirs made into disposed, polluting plastic,
    and this "CO2 thing," whose consequences seem to be increasing;
    interestingly enough, long-established balances in nature
    deal with natural product and environmental recycling,
    while short-sighted and arrogant human activity
    has its history of wreckage left behind.

    The conclusion of the moment is just one point
    on an oscillating curve of fashion cycles;
    stewardship from a vantage of greatest perspective,
    even of our production cycles, would serve us better.

    -[ ]-

  13. Re: Why new calculators will be not as good as old ones?...

    On Mon, 06 Aug 2007 08:13:03 -0500:

    > There are new "hot" methodologies - Extreme programming, Agile
    > Programming and such. The mantras are a) code first, think later, b)
    > design is waste of time, c) no documentation are needed - code is the
    > best documentation, d) client has no clue what he wants - the best
    > approach is to ignore him


    Prelude to a downhill race.

    Does it come from "Education by 'left to watch TV'"?
    (in the "vast wasteland" era?)

    "Sparing the Ritalin spoils the child"

    "Fahrenheit 451"

    -[ ]-

  14. Re: Why new calculators will be not as good as old ones?...

    On Mon, 06 Aug 2007 08:35:34 -0500:

    When you are faced with an emergency,
    local values of course favor instant action,
    often unavoidably in vacuum;
    long-term development needs other balance of values,
    to grow without becoming cancer,
    needs expanded and deeper mind,
    even to succeed in quick, instinctive actions.

    Also in politics and global leadership,
    often put in hands of people who know nothing global,
    neither territorial, interdisciplinary, nor historical;
    knee-jerk jerks.

    Developing judgment is an art,
    and takes some seasoning to learn well and master.

    -[ ]-

  15. Re: Why new calculators will be not as good as old ones?...

    On Mon, 06 Aug 2007 08:35:34 -0500, "John H Meyers"
    wrote:

    >On Mon, 06 Aug 2007 08:13:03 -0500:
    >
    >> There are new "hot" methodologies - Extreme programming, Agile
    >> Programming and such. The mantras are a) code first, think later, b)
    >> design is waste of time, c) no documentation are needed - code is the
    >> best documentation, d) client has no clue what he wants - the best
    >> approach is to ignore him

    >
    >Prelude to a downhill race.
    >
    >Does it come from "Education by 'left to watch TV'"?
    >(in the "vast wasteland" era?)
    >
    >"Sparing the Ritalin spoils the child"
    >
    >"Fahrenheit 451"
    >


    Sort of, yes...

    A.L.

  16. Re: Why new calculators will be not as good as old ones?...

    "A.L." wrote in message
    news:863eb3ltnpc7t92nhrlle2896kbrc73svm@4ax.com...
    > On Sun, 5 Aug 2007 20:56:33 -0700, "Joel Kolstad"
    > wrote:
    >>In *my* opinion, any and all BUGS should be fixed.

    > First, there is no way to find ALL bugs. Thesting can show only
    > presence of bugs, but not absence of bugs.


    I agree that there's no guarantee you can find all your bugs. However,
    there's a *huge* difference between releasing a product as soon as it compiles
    (and I've known some programmers who honestly felt "their work was done" as
    soon as their code compiled!) and making *a reasonable effort* to find bugs by
    performing "torture tests" on your code.

    > Second, the cost of bug fixing grows exponentially with the number of
    > bugs fixed. Cause is that fixinb bugs injects new bugs,


    I don't think that follows... if you have a million lines of code and one bug
    per thousand lines, you start out with a thousand bugs, right? So you
    re-write a thousand lines of code, and introduce one new bug in the process,
    which you then fix. That's not "exponential growth."

    Changing the people and the process you use to generate software can easily
    *decimate* the number of bugs you have in the first place.

    In the case of the HP 35s, how poor of a project manager do you have to be to
    *not* first yank up the list of known 33s bugs (such as COS() ) and make sure
    that all the trivial ones no that list (such as COS()! ) get fixed?

    ---Joel



  17. Re: Why new calculators will be not as good as old ones?...

    "A.L." wrote in message
    news:hq6eb3hunp14ctelqvr14qcmag2hl2tfoa@4ax.com...
    > There are new "hot" methodologies - Extreme programming, Agile
    > Programming and such.


    I've always found it amusingly ironic that Ken Beck's "extreme programming"
    came about while he was working on a project that ended up being canceled
    after not producing satisfactory results (see:
    http://en.wikipedia.org/wiki/Extreme_programming).

    Much of the extreme/agile programming ideology is bunk, but they do have a few
    good ideas thrown in too.

    ---Joel



  18. Re: Why new calculators will be not as good as old ones?...

    On Mon, 6 Aug 2007 12:34:28 -0700, "Joel Kolstad"
    wrote:

    >"A.L." wrote in message
    >news:hq6eb3hunp14ctelqvr14qcmag2hl2tfoa@4ax.com...
    >> There are new "hot" methodologies - Extreme programming, Agile
    >> Programming and such.

    >
    >I've always found it amusingly ironic that Ken Beck's "extreme programming"
    >came about while he was working on a project that ended up being canceled
    >after not producing satisfactory results (see:
    >http://en.wikipedia.org/wiki/Extreme_programming).
    >


    There was his statement somewhere on the internet: "Yes, the project
    failed, but methodology was correct"

    A.L.

  19. Re: Why new calculators will be not as good as old ones?...

    On Mon, 6 Aug 2007 12:30:03 -0700, "Joel Kolstad"
    wrote:

    >
    >I agree that there's no guarantee you can find all your bugs. However,
    >there's a *huge* difference between releasing a product as soon as it compiles
    >(and I've known some programmers who honestly felt "their work was done" as
    >soon as their code compiled!) and making *a reasonable effort* to find bugs by
    >performing "torture tests" on your code.


    Nobody says this. Product is not released 'when it compiles" but when
    "it is good enough". Huge difference.
    >


    >I don't think that follows... if you have a million lines of code and one bug
    >per thousand lines, you start out with a thousand bugs, right? So you
    >re-write a thousand lines of code, and introduce one new bug in the process,
    >which you then fix. That's not "exponential growth."
    >


    But somehow it is. There are quite scientific mathematical models of
    debugging process, and these modelssay this. These models are in
    pretty good sync with practical measurements.


    >
    >In the case of the HP 35s, how poor of a project manager do you have to be to
    >*not* first yank up the list of known 33s bugs (such as COS() ) and make sure
    >that all the trivial ones no that list (such as COS()! ) get fixed?


    People are afraid to be "first bad news messengers". This is the
    reason why we had 9/11 and why Minneapolis bridge collapsed.

    A.L.

  20. Re: Why new calculators will be not as good as old ones?...

    Hello,

    "A.L." schrieb im Newsbeitrag
    news:spveb3ldk4oedocv3gofbs9bsf5s743f05@4ax.com...
    > On Mon, 6 Aug 2007 12:30:03 -0700, "Joel Kolstad"
    > wrote:
    >
    >>
    >>I agree that there's no guarantee you can find all your bugs. However,
    >>there's a *huge* difference between releasing a product as soon as it
    >>compiles
    >>(and I've known some programmers who honestly felt "their work was done"
    >>as
    >>soon as their code compiled!) and making *a reasonable effort* to find
    >>bugs by
    >>performing "torture tests" on your code.

    >
    > Nobody says this. Product is not released 'when it compiles" but when
    > "it is good enough". Huge difference.
    >>

    >

    Not so huge difference if you remember when the 49g aka FHB was released.
    That buggy machine was the reason why a 'bugzilla-like' mechanism
    was created on www.hpcalc.org .

    At release time the 49g had hundreds of severe bugs,
    and two years after release there were still dozens of severe bugs,
    and the machine wasn't really stable.

    None of the non-beta ROM images was stable at all.

    The only (mostly) stable ROM especially for the 49g
    is the 1.19-6 (a beta, of course),
    and that ROM was released after about 4 or 5 years,
    at the end of the proposed life-cycle.

    Not too good compared to the first HP-48SX with ROM A,
    which only had a handful of bugs in the first release...

    I'm not counting the 2.xx ROMs, because the FHB
    wasn't the promary target for these ROMs.



    >>I don't think that follows... if you have a million lines of code and one
    >>bug
    >>per thousand lines, you start out with a thousand bugs, right? So you
    >>re-write a thousand lines of code, and introduce one new bug in the
    >>process,
    >>which you then fix. That's not "exponential growth."
    >>

    >
    > But somehow it is. There are quite scientific mathematical models of
    > debugging process, and these modelssay this. These models are in
    > pretty good sync with practical measurements.
    >

    Maybe on an overall view basis.
    However the 49g development process didn't fit into those models.
    And the debugging was done by the users, not by ACO.


    >>
    >>In the case of the HP 35s, how poor of a project manager do you have to be
    >>to
    >>*not* first yank up the list of known 33s bugs (such as COS() ) and make
    >>sure
    >>that all the trivial ones no that list (such as COS()! ) get fixed?

    >
    > People are afraid to be "first bad news messengers". This is the
    > reason why we had 9/11 and why Minneapolis bridge collapsed.
    >

    But the COS() Bug was known from the 33s ...
    Even hp/Kinpo should have been aware of it,
    at least if Cyrille forwarded the bug.


    Maybe someone at 'hp' remembered the extremely embarrassing
    first years of the 49g, and the useless first batch of the 48gII,
    and pulled the emergency brake...

    Maybe someone recognized that some severe bug(s)
    on the anniversary model would not shed a good light onto it.
    And I'm not necessarily talking about the COS() bug,
    because there are others, like the wrong index offset...

    From today's view, a machine like the 35s is not very complex.
    The functions and features are less than those of an
    HP-41 (12-24K ROM) or HP-42S (64K ROM) .
    So it should be possible to debug the beast
    to a certain level before release.


    Regards

    Raymond




+ Reply to Thread
Page 1 of 2 1 2 LastLast