Martin Ewing AA6E writes...
> The ideal approach, as shown by Flex Radio and some others is to work
> with the user community for software development and support. I
> clicked the "open source" box on the Survey, and I hope many others will
> do so as well. There is often more energy and talent in the user
> community for volunteer software work than there is in a small company
> that has to meet a payroll.
I'm not sure there is an ideal approach--each strategy for paying for
ongoing software development has strengths and weaknesses. Volunteers
are excellent for identifying needs, but those needs still need to be
converted to functional requirements, and then the programmers should
write code that explicitly fulfills those requirements. Volunteers are
frankly not good at sticking with that requirements-based discipline.
They tend to jump right into design solutions before being really
clear about the problem they wish to solve. The result is that the
formulation of the problem is as fluid as the alternative designs, and
the two chase each other with no clear way to determine success.
Ten Tec's programmers may actually suffer the same tendency.
I'm currently chairing a committee developing a communications
standard for a piece of traffic signal control equipment. The
committee comprises public sector, manufacturing, and systems
consulting branches of our field. We get nowhere until we impose that
requirements-led discipline. Yes, it does cost more to do it that way,
if the standard of completion is something that just works. But if the
standard is fulfilling all the requirements, then it usually costs
less. Keeping volunteer contributions properly directed is what
controls cost.
Rick's story about moving the notch filter to later in the AGC loop is
an excellent example. He implies, probably correctly, that it was an
accident--a side effect of making other improvements. Had there been a
written requirement, "The Orion shall filter out carrier tones in the
passband such that they do not continue to affect the AGC function
or the S-meter", the loss of that feature during the revision might
have been avoided. (I'm assuming Rick has diagnosed the problem
correctly, but then I trust him.)
What I would like to see is an open process for writing a detailed
description of all the various ways a radio might be used as the basis
for a concept of operation ("operation" in terms of the user, not the
system), and then a set of explicitly traceable functional
requirements for software. This is where openly involving volunteers
is most helpful and positive. Then, if one of those desired activities
cannot be accommodated in the design, at least we know it's a real
limitation and not an accident. It would also help Ten Tec avoid
spending too much accommodating activities around which the user
community has no concensus.
For example, some users are ragchewers, some contesters, some DXers,
etc., and some a little of all of these. And within each, there are
those who prefer one mode over another, or not. It might be possible
to tailor the system to each by providing operational profiles that
allow users to switch from a contesting setup to a DXing setup. When
chasing rare DX, I'm usually running two receivers and split
operation. When contesting, I'm usually not running split, though I
may want to use the second receiver for searching and pouncing while
my memory keyer (voice or CW) is calling CQ on a frequency. With
software, there is no need for the machine to be suboptimal for one
just because it's optimal for another.
To that end, the questions in the survey designed to find out how I
might want to operate my station were excellent if the results are
properly used. But even better would be a public development of the
needs and requirements.
In summary, I'd vastly rather have 100 expert users describing their
intended use in a rigorous and documented way than 100 programmers
(many of whom are amateurs, at least in this field) each trying to
design to a poorly understood ideal of operation. I think it would get
the result much closer to what everyone wants.
Rick, KR9D
_______________________________________________
TenTec mailing list
TenTec@contesting.com
http://lists.contesting.com/mailman/listinfo/tentec
|