[ct-user] A Newbie's question

[Dick Dievendorff]

Tariq:  I'm not sure how much effort it would be either.  And given enough
interest (by the authors involved or those willing to help), it might
happen.  Questions (and posts) like yours are not unreasonable.

My experience with software is that it takes a group with very different
skills to do the job well.  Sometimes one person has a mix of these skills,
but that's really, really rare.

You need a "customer champion" that understands the application very well
and has his head in the customer's world all the time. He would be a
contesting participant, maybe sometimes a serious competitor.   He uses the
product all the time, and goes to Dayton and a lot of club meetings to demo
new product features and gather input from users, potential users, and
competitors.  He'd know the features and shortcomings of all the
competitor's products. He would own the prioritized wish list of new product
feature requests.  He's a marketeer, and may or may not know how to write
professional-quality computer programs.  He probably can figure out which
change requests are really hard and which are easy. He can probably READ the
computer programs well enough to answer detailed questions or suggest an
improvement. He can USE the product very well.  Most customers think of him
when they think of the product. We'll call him the "program manager".

You need a support organization that can handle phone calls from customers.
These folks also know the product well.  They're good on the phone.  They
have telephone headsets surgically attached and they never sleep well
because of their round-the-clock shift work. They have access to a
"knowledge base" of every question they've ever heard and the right answer.
The knowledge base articles have been reviewed by the programmers and the
program manager.  They have a great collection of funny questions asked by
users.  They insulate the programmer and program manager from the "easy"
questions.  They submit bug reports on behalf of customers, and they write
up "wish list" requests for the program manager.  They deal frequently with
people who are sometimes very upset and whose manners sometimes leave
something to be desired.  They may think the programmer is an idiot and the
test organization is overpaid. Depending on the volume of calls involved,
there may be a hierarchy of skill levels in this organization.  This
organization is expensive, and the cost is hard to defend. Unless you don't
do it, then everybody screams.

You need one or more programmers.  They work long hours and deal with a lot
of grubby little details. The software he uses is always changing, often for
no apparantly good reason.  Why doesn't this "standard" function work the
same in Windows 95 as Windows NT as OS/2 as PC DOS?   He hates at least half
of the operating systems he has to write code for. He is installing new and
sometimes flakey software almost every week. The computers he has to support
are always changing.  There are dozens of new radios with software designed
by people who don't know or care about contesting requirements.  He probably
doesn't have enough time to enter very many contests; he may not even be a
contester.  He reads summaries of the support issues.  He rarely gets
interrupted by the support organization if they're doing their job.  He may
not have very good people skills - you may not ever want to frighten your
customers by introducing him to them.  He's hard to find, overpaid, harder
to manage, and even harder to replace. He thinks everything written by his
predecessor is crap and is slowly rewriting all of it, whether or not that's
necessary or budgeted. He can get a job writing software in some unrelated
field pretty easily these days.

You need a manufacturer that will ship the product, worry about gettting new
updates to users, and deal with panic requests for new versions on very
short notice. Hopefully they're good at collecting funds or you go out of
business. He spends too much money with Federal Express.

You need someone with marketing skills who manages the marketing campaign
and figures out that you can sell more units at a higher price at Dayton if
it's in a pretty box with pictures of radios and antennas on it rather than
a baggie with a diskette and a fourth-generation photocopy of a "manual".

You need a test organization that has at LEAST one radio of every supported
type (the manufacturers DO change radio characteristics without changing the
front of the radio), and a LOT of computers.  Every new product release has
to be verified against all the different permutations.  Do all the old
features work when the programmer installs a new feature?  Does the CW
keying work on all the LPT ports and all the serial ports?  Does it score
the All Asia contest correctly, given the new rules issued in Japan last
month?  Does the DVP card interact with the Donner Blitzen 64 video card? Do
we properly react to the difference between ROM version 32 and 34 of the
very popular YaeTec FT-4.98 and concurrently control the rotator when it's
offset by 90 degrees and the new multiplier in the input area wants to swing
the rotator through the stop as we send CW at varying speeds while the user
hits the ESC key?

They develop test "scripts" that every "release" has to go through before
it's released to the customer community.  They have a difficult relationship
with the programming staff.  They have to like abusing products and like the
abuse they get back when they report real or imagined defects.

They work with the programmers and the program manager to figure out which
bugs are "showstoppers" that should hold up the product release and which
bugs can be knowingly shipped out to customers.  Can we ship the product
that we've promised for this year's CQWW even if SOA in All Asia gets scored
subtly wrong?  What do we do if we can never get the bug count down to zero?
What if the manual is a little out of date, should we hold up the product to
describe a new feature, or can we describe it in a "readme" file?

It seems that every new set of features will mostly work OK, but some things
break as we poke at the code.  What used to work before doesn't work when
something unrelated changes.  It's maddening.  The more aggressively you add
function, the more things break.  If you take it slowly and carefully, you
may not be responsive enough to your customers' needs for these feature sets
and you go out of business because you're buried by someone more aggressive.

And finally you need someone with financial skills that can figure out how
to make this all profitable.  How many new copies of a program will be sold
if we support the new IcoKenSuTec 9000 radio?  Is it worth buying a radio
for the test organization for the 200 radios that will ever be sold to
contesters worldwide? If we do buy the radio and it turns out to be a dog
radio that never catches on, how do we explain our purchase decision to our
boss?

If you can sell many thousands of copies, or if you can charge a lot per
copy, you can assemble a group with these skills, because there's enough
money in it.  Getting this group together for a relatively few copies of a
cheap product is a lot harder.

I very much admire the people involved with the popular ham contesting
programs.  They've shown dedication, great resolve, and great manners.  How
do WE reward them sufficiently to make it possible for them to generate the
great software we'd like to see?  I think the answer is that we tell them of
the demand for their products, and then pay them what it's worth.  For every
copy.

I chose one radio over another because of relatively small differences.   I
spent quite a bit for those small differences.  Isn't my contesting
experience enhanced even more by a great contesting program?  Why should I
be willing to pay thousands of dollars for computers and radios but grumble
if the software costs more than a few tens of dollars?  After all, I just
get a little diskette for my money.  It seems like such a small thing to pay
so much for.

Thanks, Tariq, for bring up this topic.  Obviously you've hit a nerve with
several of us because contesting software is so much a central part of the
"contesting experience" that we all care a lot about this.

CU in the next contest!  I'll be using one of my licensed copies of a
popular contesting program.  I buy most of them.  And I think I'll always
need a QSO with AP2TJ!

73 de Dick, K6KR

--
Submissions:              ct-user@contesting.com
Administrative requests:  ct-user-REQUEST@contesting.com
WWW:                      http://www.contesting.com/ct/
Questions:                owner-ct-user@contesting.com