Author Topic: AUK Finances and Website Project was: AUK Chairman Statement  (Read 119442 times)

Re: AUK CHAIRMAN STATEMENT
« Reply #475 on: 18 October, 2018, 12:09:43 pm »
Where we go from here is difficult to devine. As Greenbank says, its hard to know how best to help.

This is mostly a project managent problem; the technical stuff is relatively straightforward. Alas, the one thing you cannot outsource is management.

Well it starts with TPTB admitting there is a problem beyond "this has gone a little overbudget", because it seems no one has any leverage to force them to. From outward appearances it appears to be very much the opposite - digging in rather than asking for help.

Until you solve that problem, discussing schemas and better project plans is pretty pointless.

(if they've now contractually committed to Phase 2, which I assume they have, the financial damage is already done)

frankly frankie

  • I kid you not
    • Fuchsiaphile
Re: AUK CHAIRMAN STATEMENT
« Reply #476 on: 18 October, 2018, 12:20:37 pm »
Surely the legacy data is the same as the current or new data? It just has older dates?

The legacy data (up to 3 weeks ago) can be seen as a very low priority sideshow.  Which is not to say it isn't important to AUK - but there's no need to build in features into the new system to handle it, it can just be dumped on the cloud somewhere and it won't go away, or just kept on the old server until that falls off its perch.

However we also have 'legacy' event entry data which is very much alive - ranging from old entries dating back several years to permanents that have not been ridden so AFAIK the entry is still valid - to entries made say 2 or 3 months ago to next year's PBP qualifiers - to entries being made right now at an average of up to 20 per hour.  This stuff needs delicate handling in any transition.
when you're dead you're done, so let the good times roll

frankly frankie

  • I kid you not
    • Fuchsiaphile
Re: AUK CHAIRMAN STATEMENT
« Reply #477 on: 18 October, 2018, 12:25:04 pm »
Phase 4d: integrate additional external systems developed by AUK volunteers (AAA checker, route planner, DIY validation, etc.)   

Phase 4d ??  We are under considerable pressure to implement this stuff right now (I have been fending off requests from Board level to put the AAA checker on the existing server - it's probably a resource hog).
when you're dead you're done, so let the good times roll

Manotea

  • Where there is doubt...
Re: AUK CHAIRMAN STATEMENT
« Reply #478 on: 18 October, 2018, 01:20:45 pm »
Phase 4d: integrate additional external systems developed by AUK volunteers (AAA checker, route planner, DIY validation, etc.)   

Phase 4d ??  We are under considerable pressure to implement this stuff right now (I have been fending off requests from Board level to put the AAA checker on the existing server - it's probably a resource hog).

Goodluck with that. With all due respect to you and the developers, the Board was responsible for specifying routevalidator, and the service has proved so unreliable that I don't use it.

Beyond that, you have to have something to integrate it with...

hillbilly

Re: AUK CHAIRMAN STATEMENT
« Reply #479 on: 18 October, 2018, 02:03:09 pm »
I was going to check some of the figures being bandied about (I thought the £27,000 a year cost was for Phase 2, not Phase 1 as implied by someone yesterday) but it appears that the Minutes have be removed (presumably innocently and temporarily) from the Official section of the AUK website.


Re: AUK CHAIRMAN STATEMENT
« Reply #480 on: 18 October, 2018, 02:04:09 pm »
(I have been fending off requests from Board level to put the AAA checker on the existing server - it's probably a resource hog).

Not sure what you base that accusation on - the development version of this, as used by the AAA sec this year, is running in a free AWS instance and has pretty minimal requirements. Everything, apart from elevation lookups, is done in the browser.
“That slope may look insignificant, but it's going to be my destiny" - Fitzcarraldo

Re: AUK CHAIRMAN STATEMENT
« Reply #481 on: 18 October, 2018, 09:10:42 pm »
I am not a computer expert but have had some experience in developing software specifications and having in built. 

My view would be that the requirements of the new system should have been written as a formal specification from the ground up using a delphi system to achieve buy in from all users.  This could usefully have been done in the 6 months prior to the reunion with a series of proposals being thrashed out at the reunion weekend.

Then a brand new database is built on that plan from the ground up using the best software. Finally a flashy front end is put on it.  For a short while the 2 systems run in tandem  (a real pain for organisers) but assures safety and then the old system is locked down and archived and the new system goes live.  Additional modules are added as required/funds/stability allows.

We seem to have put the shiny bodywork on top of a very old engine and chassis at the moment for a vast amount of money.

whosatthewheel

Re: AUK CHAIRMAN STATEMENT
« Reply #482 on: 19 October, 2018, 07:50:56 am »
I have just noticed that the AUK Website has been rated "cool" on the cool wall here on YACF, which kind of confirms what I always thought... follow me:

Audax is "unconventional" in that it doesn't follow the trend of "light and aero, fast and expensive, watts and carbon" which seems to be all the rage in the recreational cycling world and it's heavily marketed and advertised by the big players with no exception. This makes audax a bit quirky and that's the attraction. It certainly was for me. The market for quirky is actually quite big. Even Rapha realised that quirky sells!!
Having an old fashioned battered website fits in nicely with the image, a bit like those very busy greasy spoon cafes that don't even have a Website or they have one built in 1994.
Try and find a seat here at lunch time, they don't even have a website


Incidentally those places are often used as controls, which shows the synergy is real.

Is a modern, sleek interface going to make AUK mainstream? Frankly I hope not... with mainstream comes a cascade of unwanted collaterals like "liability", "support", "bad weather cancellations", "marshals", "charity donations", maybe even "profits" and all those things Audax rids of.

Maybe the stars really really wanted AUK to keep fixing the old banger indefinitely, with glue and gaffer tape if needs be, with sweat and tears, against the odds, and buying a new car (regardless of how expensive or performing) was a bad idea in the first place.

In a variant of the old adagio: "if it keeps breaking, keep fixin' it"

frankly frankie

  • I kid you not
    • Fuchsiaphile
Re: AUK CHAIRMAN STATEMENT
« Reply #483 on: 19 October, 2018, 09:10:31 am »
(I have been fending off requests from Board level to put the AAA checker on the existing server - it's probably a resource hog).
Not sure what you base that accusation on - the development version of this, as used by the AAA sec this year, is running in a free AWS instance and has pretty minimal requirements. Everything, apart from elevation lookups, is done in the browser.

Pure speculation on my part.  If I was wrong, I'm sorry.
when you're dead you're done, so let the good times roll

Cudzoziemiec

  • Ride adventurously and stop for a brew.
Re: AUK CHAIRMAN STATEMENT
« Reply #484 on: 19 October, 2018, 12:44:51 pm »
I have just noticed that the AUK Website has been rated "cool" on the cool wall here on YACF, which kind of confirms what I always thought... follow me:
Wha?? The Cool Wall still exists??!??!!!??!!??!!


Quote
Is a modern, sleek interface going to make AUK mainstream? Frankly I hope not... with mainstream comes a cascade of unwanted collaterals like "liability", "support", "bad weather cancellations", "marshals", "charity donations", maybe even "profits" and all those things Audax rids of.
Apart from marshals, I think AUK or its organisers has all those, even if they're not noticeable.
Riding a concrete path through the nebulous and chaotic future.

Re: AUK CHAIRMAN STATEMENT
« Reply #485 on: 19 October, 2018, 01:21:00 pm »
Maybe the stars really really wanted AUK to keep fixing the old banger indefinitely, with glue and gaffer tape if needs be, with sweat and tears, against the odds, and buying a new car (regardless of how expensive or performing) was a bad idea in the first place.

Well currently they’ve blown the entire budget on a NASCAR style fibreglass body shell with nothing inside it. And they’ve decided phase 2 will be a banging new stereo.

Those pesky mechanical parts are details to be worked out later.

(More seriously, the fallacy of the car analogy is while metalwork rusts and wears, software lasts forever if you only need it to keep doing the same job)

Re: AUK CHAIRMAN STATEMENT
« Reply #486 on: 19 October, 2018, 01:37:35 pm »
(More seriously, the fallacy of the car analogy is while metalwork rusts and wears, software lasts forever if you only need it to keep doing the same job)

In isolation, yes. In reality, with a computer connected to the big bad Internet, not really. Software rot has two forms that can be catastrophic in a situation like this:-

1) Aukweb is mostly written in an older version of PHP. If a new vulnerability in PHP is found it could mean a big security hole for aukweb. To mitigate the problem you might need to either turn it off or upgrade the version of PHP, but we can't do the latter simply as the current PHP code will not run as is on the later versions of PHP (without considerable tweaking to sit happily with the new version). (A PHP upgrade can also be forced as a consequence of a vulnerability in another component.)

2) Similarly Aukweb runs on some hardware. If there's a serious enough problem with a hardware component we may need to move to a new machine. A machine with similar hardware may not be available and more modern hardware may require a later version of Linux. A later version of Linux may have a newer version of glibc. The version of PHP we require may not be compatible with this version of glibc, and so we're in a similar position to #1.

A steady rate of maintenance is required to avoid these problems (by doing the necessary tweaks to the code as required for the PHP/etc upgrades).
"Yes please" said Squirrel "biscuits are our favourite things."

frankly frankie

  • I kid you not
    • Fuchsiaphile
Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #487 on: 19 October, 2018, 02:00:11 pm »
And maintenance stopped long ago pending New Website which for years has always been just a few months away, and was always assumed until very recently, to be a complete replacement.  It is the 'later version of Linux' variant of the problem that we actually encountered when we last had a forced migration (Jan 2016), Terry the admin did a great job sourcing older software and getting it deployed on the new hardware within about 12 hours.
when you're dead you're done, so let the good times roll

Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #488 on: 19 October, 2018, 02:08:58 pm »
A steady rate of maintenance is required to avoid these problems.

I agree. But if you do that stuff you don’t end up with a rusty banger covered in gaffer tape. With a bit of care you end up with something that’s as structurally sound as a new one.

Also I disagree about it being “written in an older version of PHP”, which implies it all needs binning. Some of the functions it uses are no longer supported and need substituting for the new ones. A tedious job a very doable one. And after it’s done it’s fine.

Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #489 on: 19 October, 2018, 02:58:31 pm »
Also I disagree about it being “written in an older version of PHP”, which implies it all needs binning.

You may have inferred that, but that's not what I implied. I'll add some clarification to my post just to make that clear.

Most of this was covered way back on p4 of this thread.
"Yes please" said Squirrel "biscuits are our favourite things."

Bianchi Boy

  • Cycling is my doctor
  • Is it possible for a ride to be too long?
    • Reading Cycling Club
Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #490 on: 19 October, 2018, 06:56:06 pm »
This is making quite sad reading. In my other (none cycling) life I have designed a number of data bases. I have racked my brains to see what is complex about the AUK records model and I cannot identify a problem.
Could some please tell me what is complex about the model? If it is what was done in the past then put the new events on the new model and migrate the results later. They are not requited to run the core function of AUK.
BB

Sent from my E6653 using Tapatalk

Set a fire for a man and he will be warm for a day, set a man on fire and he is warm for the rest of his life.

frankly frankie

  • I kid you not
    • Fuchsiaphile
Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #491 on: 19 October, 2018, 07:39:10 pm »
One of the main complications is caused by the deceptively niche (and very worthwhile) category of events known as ECE.  These were introduced long after the main data model outlined a few posts upthread was established, and the implementation was done in a way that broke the fundamental rule of 1 data row = 1 ride.  (I don't know why - it must have seemed like a good idea at the time.)
Since that happened some bright spark realised that 'AAA add-ons' (that is AAA points awarded to DIY rides on a per-ride basis) could be handled in the same way, and in fact AAA add-ons outnumber ECEs by about 5 to 1.
So when I said upthread that
... the Results table is a very simple thing.  Assuming one row in the table = one ride, the Awards lists are simply queries on that table, the queries can sometimes be very complex but that's no big deal, they're all stored.
I was glossing over the irony of the current situation, that the reality ain't quite like that.  We can not, in fact, simply query the results table to find a list of SRs, or even query the table for one member to find if (s)he is an SR or not.

There is other stuff that is less than ideal, and the history of that is that the data - Membership, Events/Perms, Results was originally distributed across 4 desktops in widely separated parts of the country.  Transitioning it to the online version took some years (starting before broadband) and in each area the online structure had to exactly mimic what existed on the desktop - so designed and refined by 4 individuals none of whom were computer nerds.  Anything else would not have worked, the individuals in question would have just ignored the online version and contnued to plug away on their desktops.
when you're dead you're done, so let the good times roll

Bianchi Boy

  • Cycling is my doctor
  • Is it possible for a ride to be too long?
    • Reading Cycling Club
Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #492 on: 19 October, 2018, 08:05:20 pm »
If you start knowin
One of the main complications is caused by the deceptively niche (and very worthwhile) category of events known as ECE.  These were introduced long after the main data model outlined a few posts upthread was established, and the implementation was done in a way that broke the fundamental rule of 1 data row = 1 ride.  (I don't know why - it must have seemed like a good idea at the time.)
Since that happened some bright spark realised that 'AAA add-ons' (that is AAA points awarded to DIY rides on a per-ride basis) could be handled in the same way, and in fact AAA add-ons outnumber ECEs by about 5 to 1.
So when I said upthread that
... the Results table is a very simple thing.  Assuming one row in the table = one ride, the Awards lists are simply queries on that table, the queries can sometimes be very complex but that's no big deal, they're all stored.
I was glossing over the irony of the current situation, that the reality ain't quite like that.  We can not, in fact, simply query the results table to find a list of SRs, or even query the table for one member to find if (s)he is an SR or not.

There is other stuff that is less than ideal, and the history of that is that the data - Membership, Events/Perms, Results was originally distributed across 4 desktops in widely separated parts of the country.  Transitioning it to the online version took some years (starting before broadband) and in each area the online structure had to exactly mimic what existed on the desktop - so designed and refined by 4 individuals none of whom were computer nerds.  Anything else would not have worked, the individuals in question would have just ignored the online version and contnued to plug away on their desktops.
If you start knowing that it is not very complex. Bolting on things like that and migrating the assumptions through the data and programs would have been a lot of work.
I still come back to the central point of core function. If you had manual addition of none standard events then ECE and any future weird creation it could be managed by exception. Is ECE core functionality? If you ran a business would you pay for the extra complexity to be automated given the demand?

Sent from my E6653 using Tapatalk

Set a fire for a man and he will be warm for a day, set a man on fire and he is warm for the rest of his life.

Phil W

Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #493 on: 19 October, 2018, 09:11:40 pm »
Will have to have a look at the phase 1 URLs (in pre live mode) again to see what functionality is there, particularly around results and ECEs etc. The phase 1 URLs are in the audax uk minutes posted on aukweb.

Phil W

Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #494 on: 19 October, 2018, 09:34:42 pm »
I cannot believe that something as simple as having multiple event rows for the same rider and same date would cause a doubling of project costs.

  • This would have been known from the upfront analysis
  • The code to get the right result exists and could have been examined
  • Joining a table to itself by left outer joins etc is pretty basic stuff within SQL type databases
  • Presumably even if in same table you can tell an ECE apart from a calendar event or DIY or trad perm else how on earth would the existing code work?

Stick a DBA and a programmer in a room and they would have an answer within hours at most, not £50,000 later.

Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #495 on: 19 October, 2018, 09:46:30 pm »
Unless I'm very much mistaken, Phase 1 does not contain any sort of results listings. From what I saw when I checked out the site*, it does calendar and perm event listings and a basic member login and that's it.

To reiterate, this is the list I submitted to the IT manager and he confirmed it was all in "Phase 3":
Quote
- Event entry and payment
- Event creation/admin/etc for organisers
- Event results database
- Points tables etc
- Calculation of awards etc

Your guess is as good as mine as to where the money's gone.

(* I just checked and the preview server isn't currently online)

Manotea

  • Where there is doubt...
Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #496 on: 19 October, 2018, 10:23:05 pm »
I cannot believe that something as simple as having multiple event rows for the same rider and same date would cause a doubling of project costs.

  • This would have been known from the upfront analysis
  • The code to get the right result exists and could have been examined
  • Joining a table to itself by left outer joins etc is pretty basic stuff within SQL type databases
  • Presumably even if in same table you can tell an ECE apart from a calendar event or DIY or trad perm else how on earth would the existing code work?

Stick a DBA and a programmer in a room and they would have an answer within hours at most, not £50,000 later.

Upthread it was suggested better to focus on the big stuff and forget the edge cases like ECEs. Thats basically how we've got into this mess, as you end up with loads of additional coding shoe-horned in after the event to handle the edge cases.

A similar but different problem to ECEs relates to 7x200km perms which are listed as 7x200 brevets rather than a 1400km Brevet with 7x200 validated rides.

The solution is to distinguish between the "Brevet" and the "Validated Ride"; normally theres a one to one relationship but not necessarily.

Building the system afresh would have allowed subtle stuff like this to be winnowed out, and designed into the central data structures, which in turn would make the rest of teh system realtively straightforward to implement.

The problem is that those taking the decisions don't know much about IT and those driving the technical side of the project don't have a first hand appreciation of AUK operations and running events (and I suspect nobody but Francis understands how ECEs are implemented and the developers soon decided they'd rather not have to find out!).

Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #497 on: 19 October, 2018, 10:26:59 pm »
So what happens when the next AAA add-on/ECE is invented? Is that included in the £27K maintenance fee (answer:NO). Is the code on GitHub so we can submit a PR to make it work? (Answer: NO) Have we bought the code at all or just a contract to keep the current functionality running on a new platform until we decide it doesn’t do all the new things we want it to ( I give that 3 years, maybe 5) at which point we are either over a barrel with the current supplier or start again. Again.
Quote from: tiermat
that's not science, it's semantics.

Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #498 on: 19 October, 2018, 10:42:12 pm »
There are some very good points made above by Alex, Chris, Manotea, BB and others. Audax by it’s nature is awash with IT professionals. We can see how the project could be run better. But we voted for the board to make these decisions and this is what they have decided.
Quote from: tiermat
that's not science, it's semantics.

Pingu

  • Put away those fiery biscuits!
  • Mrs Pingu's domestique
    • the Igloo
Re: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT
« Reply #499 on: 19 October, 2018, 10:42:24 pm »
...Stick a DBA and a programmer in a room and they would have a...

...fight.