[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