[TenTec] Re: Jupiter firmware problems...NOT! (SO!... )

Jerry Harley wa2tti@qsl.net
Sun, 01 Sep 2002 17:08:53 -0400

SEE doesn't even own the piece of equipment he is complaining  about. 
 Only took 30 seconds to go back tp 1.19 and watch my emails.  No 
problem, Thanks TenTec for all the nices extras you have given us over 
the past  20 months.  Jerry  one of the first Jupiter owners

John Clifford wrote:

>[Note: A correspondent informed me that Ten-Tec's firmware is now outsourced
>to a company called RFSquared... so while I am using "Ten-Tec" in this post,
>RFSquared should certainly be getting the heat -- from Ten-Tec.  As per my
>last post on this subject, even though RFSquared is doing the development,
>the responsibility for quality is Ten-Tec's... they can delegate authority
>("you guys work on this and we'll pay you... here's the source") but they
>can't delegate responsibility.]
>Re concern about quality control reflecting a "lack of forward thinking"...
>I must say that this comment made me speechless for a moment.  With all due
>respect... hogwash!
>Picture, if you will, a company like Microsoft telling it's customers that a
>new Windows release that is so buggy it can't handle mouse clicks is merely
>an expression of "forward thinking."  How many milliseconds would it take
>for a vast cry of outrage to happen, and deservedly so!  Picture them
>issuing THREE versions of Windows in a week... and none of the three work!
>Would/should they get a pat on the back for effort?  Why should Ten-Tec be
>any different?
>Re 'jumping thru hoops'... in my experience, the group most responsible for
>getting low quality to the customer is MARKETING (or those responsible for
>monitoring the development schedule) rather than Development or Quality
>Control.  Re Ten-Tec's "responsiveness"... who cares if a company can
>quickly get three releases out in a week, if all three have defects so that
>they can't be used?
>Remember... work equals force times distance.  If the stuff doesn't work,
>then regardless of how hard the developers have pushed the software isn't
>going anywhere... so no real 'work' was accomplished!  My experience has
>shown that it's far better to cut a buggy feature (or delay an upgrade
>release) unless/until it passes the necessary QC tests.  If you don't have
>the time to do it right, when will you have the time to do it again?  How
>much labor/payroll was expended doing the same job three times when it
>should only have been done once, and what new features DIDN'T get created
>because time was spent fixing and refixing and refixing?
>Re excusing firmware update bugs by comparing firmware release quality to
>the level of quality found in many shareware or otherwise not-professionally
>developed amateur radio software products... hopefully the standard of
>quality that Ten-Tec offers in its firmware releases is well above the
>average one-person hack shop (not to denigrate small developers... while
>many are outstanding, many others have no understanding of software
>engineering or software quality control).  We marvel at the outstanding
>quality put out by some small developers because it IS the exception that
>proves the rule.
>Software 'engineering' is a combination of art and science.  The art is in
>figuring out how to do something and doing it elegantly.  The science is in
>applying methodologies during development AND testing that detect invalid
>assumptions and/or conditions so that as many bugs can be eliminated as
>possible.  I remember only one 'bug' that was hardware related... a
>defective 386/33 chip that drove us nuts... EVERY OTHER BUG that I have run
>into as a software developer (my own and others') was caused by an invalid
>assumption (sometimes reflecting incredible stupidity) by the programmer
>(boundary condition exceeded, variable not initialized, etc.).
>I applaud Ten-Tec for taking a bold step by offering radios that can be
>updated 'on the fly'.  I cringe when I see them stepping on their crank by
>offering THREE update releases in a week, when only one should have been
>released (the others should have been internal releases that were rejected
>during testing).
>If I had to choose between a company with great support and average quality
>control, or great quality control and average support... I'd take the
>latter.  If I owned such a company (great support, average QC), I'd start
>kicking and screaming until QC was highest priority.  Support costs money...
>QC saves it and increases profitability.  "A stitch in time saves nine... "
>or, in other words, build a product with enough quality and your support
>costs go WAY down (meaning that you can still offer great support at lower
>cost because far fewer people need it).
>It's not about beating the dog.  It's about liking the dog, and wanting to
>see the dog continue to live because enough people like it to keep on
>feeding it.
> - jgc
>John Clifford KD7KGX
>Heathkit HW-9 WARC/HFT-9/HM-9
>Elecraft K2 #1678 /KSB2/KIO2/KBT2/KAT2/KNB2/KAF2/KPA100
>Ten-Tec Omni VI/Opt1
>email: kd7kgx@arrl.net
>TenTec mailing list