[Elecraft] Date, bugs, and features

[Dick Green WC1M]

Like W4ZV, I was a beta tester for that other SDR. Bear in mind my post of a
few weeks ago in which I cautioned about avoiding "groupie-ism" and holding
manufacturers to high standards. Here's my 2-cents on the subject:

 

1. I agree with W4TV that Elecraft should update the approximate delivery
dates for all backordered K3s. I'm as anxious to get mine as anyone, but I
was aware that I wouldn't be getting instant gratification when I placed the
order and was prepared to wait. The main reason I need this information is
not to relieve anxiety. I need it for planning purposes. As a busy guy with
lots of work and family demands, I have to schedule time to build my K3.
Also, my SO2R contest station is pretty complex, so I need to know whether
the K3 will be available for certain contests. It makes a difference in
terms of configuration changes I'm planning. I don't see any reason why
Elecraft can't publish a real shipping status table indicating week of order
and approximate delivery date (early <month>, mid <month> or late <month>),
with plenty of disclaimers. However, if they perceive something proprietary
about this information, Joe's suggestion for privately notifying those with
outstanding orders makes sense. Many companies inform customers with
backordered products when the expected ship date changes. It's a common
courtesy and an excellent business practice. Building it into Elecraft's
order process now would be a good investment for the future. The worst way
to deal with it is silence or, "It's going to be later than the date we told
you -- figure it out from small bits of data gleaned from others on the
reflector."

 

2. On the Sub-RX, I'm mighty impressed with how Elecraft has informed us of
the status, including details on the issues they're addressing. I've not
seen another manufacturer of ham gear disclose so much about hardware
development (at least, not in the era of solid-state transceivers.) I
encourage Elecraft to keep doing this, despite the backlash from
disappointed customers who expected the Sub-RX sooner. Disclosure was my
main beef with the other SDR manufacturer. For example, they wouldn't tell
us when they discovered and fixed hardware problems. We never knew when a
hardware update was released, except when a repair workorder included the
mysterious "updated such-and-such board". In the case of critical flaws, I
expect the manufacturer to replace/update  boards free of charge (i.e.,
issue a recall.) For performance or reliability enhancements, boards should
be replaced/updated free of charge if the unit is under warranty. If the
unit is out of warranty, the customer should be offered the opportunity to
have the board replaced/updated at a reasonable price. I would gladly have
paid for replacement boards to keep my radio up to date. But the most
important aspect is disclosure: tell us what's going on. I don't see this as
significant proprietary information that can benefit a competitor. I can
understand withholding the information until an approximate delivery date is
known, but total silence isn't acceptable. Like I said, Elecraft has done a
nice job on the Sub-RX issue and I encourage them to continue the open
discussion. It helps them far more than it hurts them.

 

3. I think it has been well-known that the K3 is a brand-new product that
will initially lack certain features listed in the spec sheet. Those who
ordered the radio last May should have understood this. I, for one, was
planning on waiting for at least one to two years before buying a K3 so the
bugs would be shaken out. I ordered a K3 sooner than planned because I've
given up on any further improvements to that other SDR I keep referring to,
and I'm willing to put up with some inconvenience to get a K3 sooner rather
than later. What pushed me over the edge was observing how Elecraft has been
handling hardware and firmware issues for the K3. I have to tell you folks
that it's *way* better than that other manufacturer.

 

4. Posting the bug/enhancement list is a tricky issue. I've been in the
software business for about 30 years, and have dealt with this as a
technician, manager, CEO and board member. There can be a lot of proprietary
information in such lists, especially planned enhancements. Further, it's
risky to set expectations of when certain bugs will be fixed or enhancements
implemented. Murphy rules the world of software development like no other
engineering domain. It's business-as-usual for unforeseen problems to be
encountered over which you have limited control, such as bugs in a compiler
from another manufacturer. Sometimes, despite the most careful design and
implementation, a bug may be so engrained in the software architecture that
it will take a major rewrite to fix it. It's not unusual for this to be
discovered only after significant time has been spent investigating the
cause, and an initially optimistic forecast for a fix has to be thrown out
the window. So, what to do? My feeling is that, at a minimum, reported bugs
must be acknowledged, along with a statement as to whether it will be fixed
or not, along with a priority number. There's nothing more frustrating to a
customer than reporting a bug and being stonewalled by the vendor. I think a
priority assignment is important because the manufacturer may not have a
realistic understanding of how a bug affects users, so if a low priority is
assigned the customer will have an opportunity to plead his/her case for a
higher priority. Often engineers don't know what customers actually do with
their products, so this is very valuable feedback. Beyond that, I would be
reluctant to publish the target release or release date. The risk of setting
expectations too high is great when you do that. However, once the developer
has had a chance to review requirements for fixing the problem, and perhaps
has already mapped out what to do, then I think there's somewhat less risk
in publishing an expected release and/or release date.

 

73, Dick WC1M