Software Development Goals

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Software Development Goals

NS5U/1 Jim Benson
     I am consummately pleased with my K3.  I am astounded with the raw performance and dazzled with the features.  I look forward to remaining stunned with the product as more features are implemented. Considering the breadth of uses the K3 is applied towards by the large diversity of users with widely varying technical expertise and focus, Elecraft succeeds surpassing expectations masterfully.  The fact they have incorporated in their development strategy a transparent and responsive forum easily accessible to the unqualified and very well qualified is revolutionary but sometimes reading this reflector is a little like getting my news at the pub.  

     Expectedly, just as in the pub, there is a wide diversity here of informed, misinformed, and those wishing to be informed but there is often too much conflicting misinformation containing personal views of second hand "facts" obscuring the successes with unfounded doubts which raise spurious issues.  One recurring theme concerns the perception of software failures and as yet unimplemented features.  Frequently, operational flexibility or designer prerogative is misconstrued as a failure or a bug and unimplemented features thus far have a history of being implemented.  
     Earlier technology adopters have little problem sorting through these issues.  They are usually the folks in the pub smiling and enjoying a pint before returning to the shack and playing radio.  Latter technology adopters tend to be the animated somewhat noisy nervous crew spilling their ale and prone to moan at every retelling of the latest "disasterous" development.
     When walking by the pub many folks, usually the last adopters, write off the whole pub as too unstable to consider viable.  All of us could benefit from the simple facts from the source.

     An Official List both of features to be enabled and recognized bugs might go a long way towards reducing the spurious responses and allaying the fear of features yet to be enabled.  Such a list likely already exists among the developers.

     Or did I miss finding it?  I love a good pint and a smile but sometimes I am the last to know.

Jim Benson
NS5U/1
My K3 Mojo is working

My two cents and worth just what you paid for it.
 
Reply | Threaded
Open this post in threaded view
|

Re: Software Development Goals

Julian, G4ILO

NS5U/1 Jim Benson wrote
     An Official List both of features to be enabled and recognized bugs might go a long way towards reducing the spurious responses and allaying the fear of features yet to be enabled.  Such a list likely already exists among the developers.
Jim, I don't think you'll ever stop hams from airing their opinions, informed or otherwise. :)

While I have sometimes thought that something like an online bug tracker, as used by a lot of open source software projects (an example: http://bugs.freepascal.org/) would be a nice thing to have, a way for people to report issues they have found or make suggestions for enhancements and then track the progress being made, I suspect that implementing this and then maintaining it would be a lot of work for what is after all a very small development team, time that might be better spent writing and testing code.

We're getting there, most people are happy now, but the nature of ham radio is that users have widely different priorities, and some will always find something to grumble about.
Julian, G4ILO. K2 #392  K3 #222 KX3 #110
* G4ILO's Shack - http://www.g4ilo.com
* KComm - http://www.g4ilo.com/kcomm.html
* KTune - http://www.g4ilo.com/ktune.html
Reply | Threaded
Open this post in threaded view
|

Re: Software Development Goals

W8JI
In reply to this post by NS5U/1 Jim Benson
>     I am consummately pleased with my K3.  I am astounded
> with the raw
> performance and dazzled with the features.


So am I.

The K3 is the first radio I have ever bought without some
silly engineering shortfall. The only things I see people
complaining about are specialized personal use or
application issues. It's impossible without years of field
refinement to get on the very top of the curve, but they are
already close and respond fast.

> surpassing expectations masterfully.  The fact they have
> incorporated in
> their development strategy a transparent and responsive
> forum easily
> accessible to the unqualified and very well qualified is
> revolutionary

I've been involved with other groups and it is often to get
them to even consider major issues. It's so frustrating I
vowed to never again work with a radio manufacturer. For
example one manufacturer had an amplifier keying issue. The
radio spit out RF before it told the amplifier to turn on. I
knew it was happening because my homebrew amp has a
"hot-switch" sensor that prevents keying (relay transfer)
while RF is present, and I looked at it on a scope and could
see the issue. It took almost a week of actual work to get
them to look at the problem. The engineer responsible kept
saying he checked it and it was fine, but it turned out he
never did check. When they finally checked they fixed it,
but historically everything they did worked that way. It
worked that way with ALC issues that caused keyclicks, and
it worked that way with a dozen other bugs some of which
never were resolved.

All three major Japanese manufacturers are out of touch the
same way.  It actually takes decades to address some very
simple problems.

Thankfully Elecraft has chosen a different approach.

> and as yet unimplemented features.  Frequently,
> operational flexibility or
> designer prerogative is misconstrued as a failure or a bug
> and unimplemented
> features thus far have a history of being implemented.

That's the problem I see. While there are shortfalls in
specialized areas, it is always an application specific and
design critical area like a noise blanker or IF port use.
What works well in one case might hurt other uses so they
have to find a compromise, and that takes time. They have to
learn all the different field applications, it can't really
be planned because planning would take so much time the
first radio would never leave the assembly line.

73 Tom



.

_______________________________________________
Elecraft mailing list
Post to: [hidden email]
You must be a subscriber to post to the list.
Subscriber Info (Addr. Change, sub, unsub etc.):
 http://mailman.qth.net/mailman/listinfo/elecraft   

Help: http://mailman.qth.net/subscribers.htm
Elecraft web page: http://www.elecraft.com