There's more to this than the antiquated IT systems.

The differences between "modes" (comms protocols) vary from gross to subtle, begging questions about where and how to draw the line distinguishing them.

New or variant digital modes are being actively developed.  Some are backwards compatible, some not.  Some are very obscure and never get past the drawing board.  Others flourish ... and evolve (e.g. 75-bit FT8 morphed into 77-bit FT8, then JS8 and FT4, and ... ?).  Does it make sense to offer separate awards for any of them?  If so, which ones?

It's not just about "digital".  Is USB sufficiently different from LSB to justify separate awards?  How about CW vs coherent CW, or CW sent with a straight key vs keyer vs bug vs computer?  If you receive my hand-sent CW using a code reader, is that the same as copying me by ear?  Does the former imply that my CW is of a higher quality than the latter?  Should there be an award for sending "perfectly-formed well spaced CW, free of errors"?  And does the CW speed matter?

Even RTTY has variants: I bet there are hams out there chasing DXCC on 75 baud RTTY.  Quite a challenge!  Worthy of a separate award?  What about narrow-shift RTTY?  Or mechanically generated and received RTTY?

Oh and let's not forget the zombie thread about what constitutes "an entity", even within the formally specified DXCC rules.

And are 'endorsements' separate from 'awards'?  Is a sticker sufficient recognition for the achievement?  Just how fancy should the plaque be? .... ... ... .. .

Bottom line: the criteria for awards are arbitrary.

That's not all.  There are other relevant factors such as the popularity and prestige of the awards and the associated economics.

Once you sort all that lot out, developing the supporting IT systems and processes becomes simple!

73
Gary  ZL2iFB

-----Original Message-----
From: ARRL-Awards@... <ARRL-Awards@...> On Behalf Of W0MU
Sent: 11 March 2021 05:05
To: ARRL-Awards@...
Subject: [ARRL-Awards] New modes and RTTY DXCC

I just saw post by a gentlemen in another group that said he only wants RTTY contacts for this digital award and has to make sure he doesn't pick any of the other digital confirmations from his confirmations and is still unhappy that the long standing RTTY award was modified instead of a new award being created.

Why were all the digital modes lumped in with RTTY or why was RTTY lumped in with the digital modes?

If the goal is to sell awards, and I think we have already agreed that the awards are a nice income stream to the league, why not just allow people to chase DXCC/WAS using RTTY, FT4, FT8, packtor, etc as independent stand alone awards?

The Digital award is more like the mixed award that combines CW and SSB.

Is the answer is antiquated systems?  if so, Isn't it well past time that the ARRL invest in to some current technologies to offer the Awards that the members want and not just offer awards that the antiquated systems can provide?

Is there any real desire by the board/psc/whoever to actually procure a system that can do this?  Sure there seems to be lots of talk but is there any real action?  If this is being done, when can we expect these new systems to be running?


W0MU

+ As I have posted here before, the current DXCC system is antiquated and fragile. In 2016, a project to outsource its replacement was initiated. In late 2017, the outsourced replacement project was deemed a failure, and the project was taken back in house. To staff it, the developers working on LoTW were re-assigned to the DXCC replacement project. To my knowledge, a replacement DXCC system has still not been deployed.

+ Several other significant ARRL software projects are similarly "stuck" somewhere between development and deployment (e.g. lifetime learning, association management).

+ Unless ARRL members put significant pressure on the Directors who represent them on the ARRL Board, the status quo will likely continue.

          73,

                Dave, AA6YQ 

For every software development company that can deliver finished products that meet the original needs and requirements of the organization, there are multi-hundreds who can't and won't.  The old joke about the lead telling the team, "OK, you all start coding, I'll go try and find out what they want," is far more true and prevalent than the joke would imply and universally leads to failure.

+ The reality is that most users of software don't know what they want. They aren't usability experts, or trained "user experience" designers. They can provide excellent feedback on an application they're using, and tell you what functionality is missing, but most can't tell you how best to deliver that functionality in a manner that will be frictionless to use.

+ Spending years collecting requirements, designing a system responsive to those requirements, implementing that design, testing that design and the for the first time putting that system in front of users RARELY WORKS. The requirements you collected were likely incomplete and inaccurate, no matter how well you listened to users. Years after you started, your finally discover your biggest mistakes - after large investments in an architecture and an implementation of that architecture.

+ What actually works? Iterative development. You have a new user interface paradigm in mind? Spend a few months implementing a piece of it in the current LoTW, so that users can immediately put weight on it -- and provide accurate feedback as to its applicability and usability. Instead of discarding the current implementation of LoTW and working for years to pull a brand new rabbit out of the hat, improve what we have - increment by increment - with user feedback a continuous part of the development process. Sure, we need a multi-year roadmap to guide this process, but the roadmap should be updated based on user feedback and emerging organizational needs each time a new increment is made accessible to users - typically 3 or 4 times each year.

+ This not rocket science. The transition from "Waterfall" to "Iterative" software development began decades ago.

       de AA6YQ