parkrun is probably a much simpler model. Person X did run Y on date Z in time T is the bulk of it (you may think AUK's model is roughly the same but it really isn't)
Maybe that's how it should be.
I personally think this is a good point to be honest - AUK's business logic
is currently fairly complicated, but does it
need to be?
Why is it actually
necessary to have an
automated system where
Rider has achieved award X if they've done this set of rides, of this sub-type or this sub-type but not this sub-type, within these dates, except these rides that are tagged like this, oh and one of the rides that could qualify could actually be made up of 2 different rides (a calendar ride and an ECE) so you need to take that into account.
Oh, and some awards have sliding time windows (i.e. a B25000 or whatever it is that has to be done over a 6 year period) so you need to check each possible sub group of rides to see if any subgroup qualify for the award, etc.
Oh, and for this award (RTTY) this ride can definitely count for this month or possibly be counted for the following month but it needs a human to confirm that at least 200km of the ride was done in the later month, etc, etc.
What is the cost benefit analysis of business rules such as the above - i.e. if it costs £x to develop/maintain business rules such as the above, how many riders (y) would leave if you didn't have it?
If £x > y x £membership fee, then it isn't worth it.
The big step (that for whatever reason hasn't been taken) is breaking the perception that what it must continue to do is defined by what it currently does, i.e. that all functionality must be kept.
If you just said - right, from now on, in the new website, we are just going to have: (to paraphrase) Person X did ride Y on date Z. And that's it.
How many people would actually say right, well that's it - if I can't have award X for having done 2 different rides one of which was in a certain time window then it's just not the same to me, so I'm upping sticks and leaving.
You could
even simply use smoke and mirrors:
An "award claim service" which simply has a multi-line text box asking riders to list the rides they've done and a big submit button at the bottom to claim the award.
Oh but pray do tell, what incredible algorithm could possibly parse this text to decide whether the rider is worthy of the award?
function DoesRiderGetAward(string claimText)
{
return true;
}
No! But riders would simply claim anything and everything!
Would they though? Really? Aren't we basically taking their word for it anyway that they've even done the ride at all in the first place?
There's no-one checking.
You simply display the certificate and a "well done" message, send the badge if they've ordered/paid for it, but just display a caveat that "claims will be reviewed on a regular basis for integrity".
This "reviewing" can then either be filled by as much volunteer time as anyone who can be arsed wants to put into it, or simply serve as similar to the tv license detector van.
You can still let organisers write complicated rules for the criteria for an award, but why do you need an automated algorithm to decide whether people have fulfilled it or not? Just allow claims and (claim to) audit a percentage of them manually.
This might seem a bit like making it all too simplistic but you aren't actually taking anything away from the member experience.
You could claim an award before, you still can now.
I'm slightly with S2L on this that there is no inherent value in that particular code.
To say there is value in the
actual code, rather than simply the maintenance of the awards, requires believing in the notion that members would actually leave AUK if it doesn't have an algorithm that automatically rejects invalid claims. Taking this to its logical extreme implies they would put it to the test and base their membership renewal decision on the effectiveness of the algorithm, which when you think about it is a bit silly.
This might seem a bit of an arcane way of thinking about it, but it's really nothing more than a creative way to avoid cost.