[PaQSO] PA QSO Party Software
Goody K3NG
goody.k3ng at gmail.com
Thu Nov 1 11:01:58 EST 2007
Obviously there needs to be a balance. We need good software for the
party but likewise we're here to operate during an enjoyable event, not
just to provide a software development opportunity. That was my main
point. We shouldn't be so bull headed as to dismiss ideas solely based
on the impact to software. While I have a lot of gratitude for the
software maintainers, I don't think their needs alone should drive the
Party. If we want to implement a change and a software developer says
they won't support it, hence ending the use of that software, if we have
four or five other specialized programs still available and several
multi-contest programs (i.e. N1MM), the impact to the Party will be
minimal and we should continue on with the change. If multiple
specialized program developers raise issues, then we may want to
reconsider. I think that's a reasonable approach, would you agree?
Something else to realize is that the amount of work to implement Party
rule changes in a piece of well designed software is likely to be very
small compared to the grand scheme of things when you consider the
amount of time it takes to develop features like dupe checking,
reporting, rig control, CW memory macros, etc. Some programs are easier
to maintain than others (I've both developed and managed development at
work). Does the program have to be recompiled when a section is added
or changed or was the program designed originally to be "data driven"
and such changes can be implemented merely by updating a lookup file or
database row? Design decisions that were made early on may have a big
impact later. If the program is a DOS program that was ported to
Windows, and it still looks like a DOS app, chances are under the hood
it's probably a pain to maintain the code. It's a fact in life with
software, to some extent there's a Darwin's law where only the fittest
or the most adaptable survive. Any DOS app from 1984 just isn't going
to be supported forever. The Party rules shouldn't stay in the 90s to
support 90s programs or programs that can't cope with minor changes due
to software architecture.
I doubt software developers get into this with what they will endure in
mind, but any programmer worth his salt knows what they are getting
into. And they do it or at least should do it because they like to
program, just like we like to tinker with radios, otherwise we'd all
sell our radio gear and just use cell phones. When the enjoyment to
"work/pain/family commitment/real life" ratio gets tipped in the other
direction, we will undoubtedly lose a developer.
John Bednar wrote:
>
> I am not saying that changes shouldn't be discussed or considered, I
> just have a different view of the statements below.
>
--
Blog: http://thek3ngreport.blogspot.com/
More information about the PaQSO
mailing list