Join Bridge Winners
All comments by Nicolas Hammond
You are ignoring the author of this comment. Click to temporarily show the comment.
Well, it's complicated…..

ACBL was the customer. Contract stated a monthly status report. But not the contents or format or distribution. ACBL wanted a change in how reports were done. You do what customer wants. I did CMA (Cover My) by sending two reports.

Internally within our developers, I wanted a monthly status report; yes, there were other avenues (project Wiki) but everyone likes reading what is going on. Monthly is common; each employee/contractor also had to provide a brief monthly report. Me writing one that tied in everyone's work made sense.

When ACBL asked to remove items that were their responsibility, technically it was correct. I should not be providing status report on what they were doing. That was their responsibility, not mine. I keep referring to the difference between the ACBLscore+ Project and the ACBLscore+ Contract. The Contract required ACBL to do certain work, but providing resources for that work and getting it done was not our responsibility.

The reports I was sending went to a large group. I could see the point that ACBL did not want to share what they were doing with the project with the larger group that I was emailing our monthly status reports to.

So… you can argue that I was fulfilling the contract terms by sending a monthly status report. But some months parts of that report were sent to a restricted group within ACBL as per customer request.

It was clear to ACBL (and me) a few months before the end of the Contract that the Project was having difficulties. How ACBL wanted to handle that was up to them. Per terms of contract, the monthly status report was for ACBL, so at their request, it was only sent to them. I did not send out our status reports to the previous larger group.
Dec. 28, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
One of the underlying problems with the current location of the ACBL HQ is that it is difficult to attract, and keep, good IT staff. ACBL is a non-profit; the pay is probably less than the commercial market in that area. Horn Lake is not a hot-bed of IT.

There is little career opportunity. Some of the IT folks have been there for many years, therefore the chance of career advancement is low. The IT work is most routine; little new development, little new modern software. It is not likely to attract newer IT staff.

This is not a complaint on the current IT staff. They have kept the engines running for many years.

With all software projects, including those that Kevin mentioned, the on-going support/maintenance is an important factor. Combined with the abilities of in-house staff.

“Best practices” vary. What may be considered best practice in one industry may not be appropriate for ACBL.

As some examples, you don't “need” code control if it is a one person development environment. ACBL is a Microsoft/IBM environment, so the knowledge/tools available in other environments are lacking. But, adding more tools/different environments adds to the IT support costs so there are always trade-offs.

Whenever you look at the IT department of an organization you have to remember that the people there are the ones that have to be able to support anything new.

Not a complaint/criticism of anything Kevin wrote; just a statement that whenever you look at something you have to be practical about the resources available.

ACBL have had a hard time in keeping new IT hires. Some will last a few weeks and then leave because there are better jobs (better paying/more opportunities/more modern computing environments) elsewhere.
Dec. 28, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
The RFP was to implement the same functionality as ACBLscore, but use modern tools/UI. It was not to create the same UI.

https://www.youtube.com/watch?v=4ufahwQOmbk is my typical example. Most clubs use the same strats each day/week; so Bridgescoreplus lets you create defaults. I don't have a video of the Club pair game set up, but you can set up the defaults for each day. I'll see if I can post one some time.
Dec. 28, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
The decision to drop ACBLscore+ was made on legal reasons. This is my belief.

Current ACBL management and current ACBL league counsel were responsible for the original ACBLscore+ contract.

About a year into the contract, the ACBLscore+ contract was reviewed by outside legal counsel for the ACBL.

The outside legal opinion was that ACBL should own the copyright to the code. This was not in the original ACBLscore+ contract.

ACBL management stopped paying invoices to force my company to re-negotiate the original contract. We said no. As others have posted here, it is extremely normal for contracting companies to be able to reuse code for future projects. In fact, as part of the ACBLscore+ contract, HS was providing code from previous work. It was a requirement for HS to do future work with ACBL that we would have to re-negotiate the copyright terms of the ACBLscore+ contract. We said no.

After the contract was over, ACBL spent even more money with lawyers to determine the legal state of the code. Based on this advice, ACBL senior management and league counsel decided to drop all the ACBLscore+ code.

They now needed to find a good reason for dropping ACBLscore+. Admitting that they had committed all this money, but ACBL did not own the copyright would not look good. ACBL senior management and league counsel were responsible for the original contract. New lawyers told them they could proceed with the code. What could they do?

ACBL senior management and league counsel threatened board members with disciplinary action (and may have followed through with this). No board members were allowed to see the original contract.

I do not know when or if ACBL management/league counsel reported to the board about the copyright issue. But it should have been before the Nov 2013 board meeting.

Of course, I could be totally wrong. The ACBLscore+ code could be a POS.

There is still work to complete ACBLscore+. I've alluded to the missing specs, and therefore the missing code. ACBL could have decided that it was cheaper to put all the functionality of ACBLscore+ into ACBLscore rather than them internally finishing the missing code in ACBLscore+. I will completely disagree. You will probably now hear this as the main reason for getting rid of everything. ACBL have admitted internal problems with providing specs for ACBLscore+, ACBL have taken responsibility for this. What happens going forward is up to them. It's cheaper (IMHO) for them to bring in-house staff and finish ACBLscore+ than it is to try and maintain ACBLscore. That was the purpose of the ACBLscore+ work in the first place - rewrite ACBLscore in a modern programming language, make it much easier/simpler to use, easier to support/debug, easier to add new features. However, ACBL management/league counsel are trying to cover up the copyright issue.

Having me show the software anywhere is not good for management or league counsel. It goes against their stated reason for abandoning ACBLscore+. I've been threatened with a permanent ban from ACBL by management/league counsel if I continue doing what I'm doing.
Dec. 27, 2014
Nicolas Hammond edited this comment Dec. 28, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
Ha! Don't take the over/under.

The ACBLscore+ code is about 200K SLOC (Source Lines of Code). About 3,000 pages if you print it. I've got a long way to go and that's not including the Wiki, design documents, status reports etc.

The contract required a monthly status report. This was something I wrote and was sent all developers, all on the ACBL management team, and also included some board members. There's probably another 1,000 pages in the monthly status reports. And some months there was more than 2 status reports.

I would write the monthly status report, send a preliminary copy to my ACBL contact to make sure I had covered everything, then after review I would send the report to everyone.

About a year into the project is when problems started.

Around then I was asked by my ACBL contact to remove all references in that month's status report to anything that was negative towards ACBL, i.e. anything that we were waiting on them for.

So that month we had two status reports. One that went to everyone, including some board members, that was a sanitized version of affairs and one that went to just ACBL senior management that listed the ACBL-only issues.

Eventually for some months, I would just write two status reports. One for everyone, one for ACBL senior management.

Tracking the ACBL issues that we were waiting on only once per month was not frequent enough, so I moved the list of issues on to the Project Wiki so there was more visibility in tracking the issues.

Towards the end of the contract, I was asked to stop sending status reports to everyone. The status report was only sent to one person at ACBL. ACBL knew at that point that there problems and wanted to control the message.

The ACBLscore+ contract only called for written monthly status report from HS to ACBL. It was up to ACBL to determine who got the report.

I assume that ACBL were also writing their own internal monthly status report to track the various issues. I had asked them to do this, and asked to be on the distribution list, but I never received one.
Dec. 27, 2014
Nicolas Hammond edited this comment Dec. 27, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
I had made the previous offer (run Bridgescore+ at the Providence NABC) privately to ACBL. I'm traveling at the moment, but when I get back I will make ACBL the same offer for New Orleans (NO). Only this is now a public offer. I'm only going to be in NO for the second week. My suggestion is that someone do the metrics on the first week morning Regional KOs and then we can compare with the second week.

For metrics, record the time of the last entry, or the event start time, whichever is later. Record the time that the first table assignment is up, record the time that the last table assignment is up. Also record the number of TDs assigned to start the event.

I'm so confident with Bridgescore+, I'm going to handicap myself when we use Bridgescore+ to start the KOs. I only want 1 ACBL TD. This TD will sell the entries. I want to make use of a caddy. Different caddy every day. Will meet 20 minutes before game time. That's enough time for me to train a caddy to do data entry for the event. If no caddy, I will do the data entry. Or, can train an ACBL TD. Purpose of different caddy every day is to demonstrate how easy the system is to learn. Also, this is the best way at tournaments. We usually have caddies with nothing to do until game time. Let's use them. ACBLscore data entry is complicated so only TDs do it; Bridgescore+ data entry is so easy, I use caddies. Will give me time to enjoy the morning beignet.

At least five minutes before game time, I will want the “table inventory” (the list of tables assigned to the event).

The ACBL TD will be the one that determines the bracket sizes, and who is in which bracket. I never get involved with those decisions.

Bridgescore+ is simply automating the tasks of bracketing/matching/tabling. Bridgescore+ can do a lot more (it can run the event from start to finish), but we only need to use a small part of Bridgescore+ for this test. ACBL can still use ACBLscore to “run” the event.

Same offer as before. I don't want to get paid. I'll bring all the equipment (printer/projector/local WiFi). Can brand it as ACBL. ACBL logos etc.

If ACBL want to have some TDs trained on the software while we are running this trial, that's fine. Happy to train them in how to use the software.

It should be a win/win situation for ACBL. If it works, ACBL can take all the credit - it's a small part of what they paid to get developed so they are using it. If it doesn't work, then they can claim that they were right to throw it all away.

If ACBL takes the offer, I will assume that they will be running ACBLscore in parallel as a hot backup. We have a process for this. It takes a little time for DICs/sponsors to become comfortable with change. I have no problem with having a hot backup for the NABC. For the regionals that I go do, and where I have worked with the DICs in the past, the DICs are all now comfortable enough that they do not use a hot backup, or indeed in most cases we don't run a backup at all.

Compare the metrics for starting the KOs with Bridgescore+ and without Bridgescore+. If Bridgescore+ is worse, stop the test.

I will predict that Bridgescore+ will be much, much faster, and only requires the 1 ACBL TD. Players will start playing quicker. It's much less stressful for the TD.

There would be no cost to ACBL for this trial.


Let me extend the offer even more. I really want to use Bridgescore+ for one of the national Swiss events. Once you have seen a Swiss run using projectors, you will never want to go back to the rack on the wall. Bridgescore+ can run in parallel with ACBLscore do to this. No more craning to read table assignments from the rack. The event also needs far fewer TDs. For the NABC Swiss, there is normally 3 TDs at round change - one entering scores into ACBLscore, one writing the team total on the Jeffrey's Chart, one putting up table assignments in the rack. This is replaced with 1 TD entering scores with Bridgescore+. And it is much easier to see who is winning the event etc.

I'd planned on playing in the NABC+ Fast Pairs for the last two days of the New Orleans NABC. However, if ACBL are willing to run ACBLscore+/Bridgescore+ for the NABC Jacoby Swiss Teams on the last weekend, I'll skip playing in the Fast Pairs and volunteer to run Bridgescore+ in parallel.

If I were ACBL, I'd want to see Bridgescore+ run a large Swiss event before agreeing to this, so I will be happy to fly to a tournament that has a large Swiss, preferably one being run by the same DIC that will run the NABC+ Swiss. I will pay my own way.

I will bring all the equipment etc. No cost for ACBL.

It's also much easier to get leader boards from Bridgescore+ so that they can be posted on the Internet.

I'm making all these offers (and I will honor them) to make it clear to everyone that the reasons for throwing away ACBLscore+ are not technical.
Dec. 27, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
A few weeks before Providence, I asked ACBL if they wanted me to run ACBLscore+/Bridgescore+ for some of the events. I was playing in the afternoon/evening sessions so I offered to run Bridgescore+ to help start the Regional KOs in the morning. I made it very clear that I did not want to be paid. I was volunteering my time. I would bring all the equipment needed - printer/projector/WiFi. I would work with whoever to help determine any future hardware needs so they could do this themselves. I was happy to brand Bridgescore+ for this tournament as ACBL software (e.g. display ACBL logo etc.). I was going to be there the entire time. I offered to do this for all the morning KOs (9-10 days). I wanted to do this to help train the TDs in ACBLscore+. Even if ACBL decides to throw all of all ACBLscore+ and rewrite the same code themselves, Bridgescore+ can help in the interim. The start times for KOs with Bridgescore+ is within a minute of game time. This saves a lot of time for the TDs and the players. We also need fewer TDs to start the event.

ACBL league counsel said no.
Dec. 27, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
You can carve out the current Pascal code, or you can say that an ACBLscore replacement needs to have the following features/functionality. Two ways of looking at the same thing.

Jim had lots of #ifdef win32 because the DOS and Windows versions shared code. From memory, he used different versions of the compiler to generate the DOS and Windows code.

I'm not going to get into a numbers game. 200,000->40,000. ACBLscore+ has about 200K SLOC (Source Lines of Code). It has roughly the same feature set. ACBLscore+ has comments. About 37K lines of the ACBLscore+ code is the “workhorse”, i.e. the code that implements the business logic. So, we are not too different.

Rather than sketching out a design, you can do a data flow diagram. What data needs to go to where, when, how and why.

Note that the biggest cost of club games is customer support. Any changes to the code has an impact on customer support.

Let me answer some specifics:

ACBLscore is the only horse in the ACBL town. There are other software programs out there. I've referred to some previously.

Masterpoint calculations are easy (relatively). Masterpoint assignment/eligibility is not. The current ACBLscore masterpoint code is replicated in 3 different places. I never got the specs on masterpoint assignment/eligibility from ACBL. This was probably a 2 week project, 4 weeks elapsed for them. Trying to reverse engineer all the rules, all the rounding calculations is a lot of work. If ACBL can provide this document (it was in the contract), then we can do testing of Bridgescore+ much easier. The problem is that the specs are not in one place, the ACBLscore implementation does not match the masterpoint calculation specs leaving it very hard to replicate the current code.

There was litte/no scope creep in ACBLscore. If there was something outside the contract, we did not have time to do it, so we would stub it out. At one point, ACBL said “no printers (at tournaments)” (I'm serious!). So we had to find a way to run events at tournaments with no printers. Projectors became the only solution. So ACBLscore+ has a projector output capability. ACBL later changed their minds about printers at tournaments so what looks like scope creep really wasn't. So… projector output was not in the RFP. Printed reports were. As a CR, ACBL took out printed reports, we replaced it with projector output, then ACBL changed its mind and wanted printed output as well. Obviously we still have some printed output. Displaying on a screen, and printing are similar, but different with web pages. We just need a little more CSS. For example, we don't need to print the menus if outputting to a printer. At some point, I'll put up a Youtube video showing some of the screens and how the output is different on a printer than on the screen.

There have been several new features that I have added to Bridgescore+ that are not in ACBLscore+ because I see how TDs work at tournaments and sometimes there are much more efficient ways of doing things. But ACBL hasn't paid for any of this work, so it's not really feature creep. Just code I've written to help run tournaments. My District (I'm in D7) wants to use Bridgescore+, they've seen it in use at their regionals, I've committed to providing it, so I'm going to make our tournaments better. While I have no marginal costs (I've prepaid various Internet hosting sites), I've made versions of this available for other districts (at no cost).

I did talk to the folks from Bridgemates and the other Electronic Scoring Device (ESD) companies. Many times. I went to some WBF events to see how they ran (not on ACBL $$) and met with them there.

I set up a meeting in Atlanta 2013 at the NABC between me, ACBL and Bridgemate to define what we would want for Swiss teams. ACBL didn't show up “too busy”. Without a long term commitment from ACBL, Bridgemate were not going to invest the time/money to provide some add-on features.

I still want to see this project succeed. I met with the Bridgemate folks in Providence, last month. I outlined what we would want to be able to run Swiss events in Bridgescore+. The current implementation of Swiss events in Bridgemates is a little complicated. You have to mimic various pair game movements. It can be done, it's just a horrible way to do it. Bridgemates are coming out with a new firmware release next year that works better. The Bridgemate folks are very receptive. I described why various features would be needed (in ACBL land we have different expectations of a Swiss than other places). Some of these changes are probably trivial for them, but will make running Swiss easier. I think after they met with me (I've been meeting with them for 2+ years), they then had a meeting with ACBL. Our design for Bridgemates (and other ESDs) is simple - we have a simple client that runs on a Windows box that has the ESD server. This client communicates to the scoring machine. This design keeps the code away from the scoring engine. It also allows one scoring machine to handle many servers (in current ACBLscore the practical limit is one server per scoring machine, which works out to typically 6 sections).

I had a prototype of a Swiss solution that I ran in a recent regional in Augusta. Unfortunately the regional was understaffed. When testing new software at any event, the current players should come first. We should not impact them. So I could only do a couple of Bridgemates at two tables. But even then, could not always run them because the TD was struggling to run the event, so I spent most of my time acting as a TA. I always asked players if they would mind running the Bridgemates; during one round a player politely, but firmly, said, “no”. So we didn't run Bridgemates for that round.

I've been paying the developer who worked on the ACBLscore+ Bridgemate code for the last couple of months as it is a feature I'd like to see. We have a good design for it. But I may wait until Bridgemates come out with their new firmware before we spend any more time on it.

There are current solutions to running Swiss on ESD. Bridgepad has one; it has been used at NABCs. There is a software package from the UK that runs Swiss on Bridgemates. Some clubs/tournaments use it.

Before the RFP, I provided ACBL with a “Risks” document. It identified the known risks, how to mitigate and how to mediate. One was that they needed to have a competent project manager working on the project from within ACBL. My role was as the program manager/product manager (call it what you will), but only for the software as it applies to the ACBLscore+ contract. ACBL internally were responsible for ACBLscore+ project. So, I was not the “ACBL ACBLscore+ Project Manager”; I was simply the contractor running the ACBLscore+ software component. ACBL had 4 different ACBLscore+ Project Managers that I reported to during the tenure of the ACBLscore+ contract. Two are no longer with ACBL.

To give one example, ACBL were supposed to provide “1.5 staff personnel equivalents” to work on the ACBLscore+ project. Their role was to provide “information and co-ordination… to assure that ACBL responsibilities under this Agreement are performed.” This didn't happen. So lots of co-ordination work didn't happen. It puts the project about 3 man years behind. To make it worse, when someone was assigned to work on something that was related to ACBLscore+ work, their manager would not let them talk to me (separate topic). Couple of quick examples: I requested a TourneyTrax login ID around Jan/Feb 2013, soon after TourneyTrax launched. By March 2014, end of contract, I still didn't have one. It took several months to find out how they wanted ACBLscore+ to send data to ACBLscore, during this time they were sharing information with other companies, but refused to provide any information to us on what the protocol might be, or the format might be. I was told, we are working on it, got some issues, got some security issues, but we will tell you when we are ready to tell you (this one is not a direct quote, I'm paraphrasing.

Agile means many things. We had software that was ready to be released just over one year into the contract. Contract started April 2, 2012. In April 2013 at the Gatlinburg Regional we showed our ACBL contact ACBLscore+ running a pair game. We took Bridgemates from the I/N area during the break between the afternoon and evening sessions, entered the results from the afternoon I/N game on the Bridgemates (two of us from HS, one from ACBL), rescored it in ACBLscore+ and showed that the results were the same, same printed output (printers allowed at this point!), same masterpoints etc.

We wanted to release this software to 2-3 clubs but under strict control. The software would not be the primary scoring machine (ACBLscore would be). We wanted to get feedback from these clubs in ACBLscore+ usage, make improvements based on real world usage. We had identified the clubs we wanted (bigger clubs, Internet connected, smart club owners/managers, physically close to developers, willing to work with new technology). ACBL said no.
Dec. 26, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
Joe: Not sure what you mean by “buffer underrun”. Let me know and I'll give an answer.

Ed: ‘Selection of movement’ is one of the ‘problems’/'issues' with ACBLscore. Particularly for a new user. “It's complicated”.

With ACBLscore+ I wanted it to be a lot easier to start/run a pairs event, the most common thing with ACBLscore. I asked ACBL for a “best” list of movements for 2-25.5 tables. “Best” is subjective. What is mathematical best is very different from what you may choose. You may run a 6 board, 4 round Mitchell with 7 tables if they are I/N players. Not the best mathematically, but I/N want to play, they take longer to play each board. At the same tournament you may do something different with I/N, gold rush, open pairs even if they have the same number of tables. Your club may not want to run Howell, because everyone gets lost, so you always run a Mitchell. Anyone, don't want to get into a religious argument about ‘best’ movement. But improving selecting a movement was a big part of the new design. The request took about 5 months (I'm traveling, not on my main computer, so this is from memory). I had estimated it as less than 1 week of work from ACBL, probably 2-3 weeks elapsed because the work would need to be reviewed by several TDs and an outside limit of about 4 weeks to allow for some delay. That was my estimate, I asked for this about 6 weeks in advance of when we needed it. And I made sure that ACBL knew it was critical path. Around the same time, ACBL had stopped paying invoices. As I was waiting on movements, and HS was not being paid, we put the developer working on movements on ‘furlough’. Basically all work on movements stopped. The delay on movements code was about 6 months. That was the 5+ month delay in delivery of movement document (and I only got pairs events, never got a BAM or individual movement document, so BAM/Individual never completed). Movements were a critical path item when the contract started (TFR was the other), so a final rollout of the pairs code is delayed by 6 months.

We can run a simple pairs game, we can import a current pairs event from an ACBLscore game file irrespective of how complicated the movement is, we can re-score, re-rank, re-qualify, re-masterpoint the pairs event in Bridgescore+. The part that we don't have is the EDMOV functionality in ACBLscore. So, we can run in parallel, but not take over completely from ACBLscore. When I wrote the roll-out document, this was the work that I would have someone do in parallel. Re-creating the EDMOV functionality is difficulty. ACBLscore uses 5 levels of indirection to go from a section down to a table result. ACBLscore+ uses 3 (board->board_table->board_table_score). For each board, you have a set of board_tables (who plays that board at which table in which round), and for each board_table you have 2 (pairs) or 4 (individual) scores. Most of the time, the EW scores and NS scores are the exact opposite of each other, but not always. Pretty much all Pairs event work stopped around August/September 2013, about 17-18 months into the contract. For testing, we import tournament/club game files into Score+, re-score everything, then compare. For a roll-out, I'd want to run Bridgescore+ in parallel with ACBLscore (we can read the BWS file that ACBLscore is also reading). While we were working on improving the UI for CDs/TDs for pair events, we would finish out the movement code. The developer I had for movements (this was the hardest person to find, you have to really understand the mathematics behind movements, fouled movements etc.) is still available; but it is still quite a bit of work both in the design, the UI, testing and implementation.

On the list of contacts that I had for ACBLscore+ were some new club managers. Smart. Young (let's define that as young enough to grow up around computers). But had no desire to learn the intricacies of ACBLscore. I used them for feedback on how easy it should be to start/run/edit a pairs event. You can see the work in https://www.youtube.com/watch?v=4ufahwQOmbk. This video is from some time ago.

Being able to define your own movement is also important. But this is a very small audience. ACBLscore has this ability. In ACBLscore+ we import the same files.
Dec. 25, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
I've heard the 5% number as well. ACBL has about 3,000 clubs. I think about 100 still turn in paper sheets.

We were expecting the same with ACBLscore+. It would be some time before everyone transitioned to ACBLscore+ from ACBLscore. What would drive people is that support for ACBLscore would slowly be dropped and as new masterpoint changes were implemented in ACBLscore+ (and not put in the legacy ACBLscore), or new months with “triple masterpoints” became available only in ACBLscore+ then people would migrate.

As ACBLscore+ can import an ACBLscore game file, worse case scenario would be clubs would just email/FTP/upload old game files to the next system. We could automatically process them.

Anyways, that was the plan. Not sure what is going to happen now.
Dec. 25, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
Probably the next large IT project within ACBL will be a DB upgrade and migration from RPG. There is a lot of internal RPG code; but at some point the developers/maintainers will retire. Either they need to be replaced, or an upgrade to a more modern environment. IBM keep supporting RPG so there is no worry about upgrade. But, there is a lot of code in RPG, lot of work to replace it with a different language. There are some legacy “features” within ACBL's environment (see earlier).

But this project may be many years out.
Dec. 25, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
The ACBLscore+ contract was not terminated. It finished.

The ACBLscore+ contract was a time-limited and dollar-restricted contract.

ACBL are attempting to portray this as something that it isn't in attempt to shift focus. HS actually terminated the contract early (OK, I'll be nice and say it was a mutual termination) effective March 31, 2014. ACBL agreed. We walked away from money in the contract. But I could not do work where they would not provide specs and it felt wrong to take their money. We had given them the required 60 day notice to fix this material breach in mid January, 2014.

ACBL then came back and wanted to change the contract end date to mid May to include the code that they saw demo-ed in Gatlinburg in April 2014. We said sure. It was the first time a large number of players had seen the code, and the first time a lot of ACBL TDs had seen it. We agreed to change the date. I continued to work on the code through mid May 2014. We billed them the remainder of the money in the contract. We sent the code. At that point the contract was over. Over. Finished. Done.

We had done what we said we would in the contract. ACBL had paid in full. The last item in the contract was to run at a major tournament. ACBL stopped this demonstration at the first event at the Dallas NABC in March 2014. They didn't want to see any more.

ACBL are attempting to claim that they terminated the contract. This is not true.

ACBL/HS could not agree on a new contract. The sticking point being re-negotiating the old contract and ACBL wanting to remove all of HS rights to the code. So we agreed to disagree, and move on.

The good news is that HS has rights to the code. I'm offering it for free to any District that wants it. That's the irony of this situation. ACBL are claiming it is useless. I'm claiming otherwise and running it at tournaments. ACBL are now spending more money to put the features of Bridgescore+ into ACBLscore. That is the disconnect that everyone is finding puzzling. If it is useless, why do I run it? The results speak for themselves. See http://bsp.bridgescoreplus.com/?page_id=145 where I wrote up each event along with the time savings.

Of course, my claims could be a POS (Piece of, well you can figure out the rest). I'm willing to stick my reputation on the line to state otherwise. And have done, see the tournament where the software has been run. See the comments from various TCs. See the comments from the players where Score+ has been run.
Dec. 21, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
I'm just quoting what I was told to do.

History of TFR:

Agreement to use Excel (this is still the correct technical implementation) was somewhere around April/May 2013.

First prototype done June/July 2013. Needed feedback. Basic prototype showing how it would work. Locked cells. Color. Filling in custom defaults possible before shipping XLSX file. Could be stored/worked on in cloud.

Demos given in Atlanta July 2013 at NABC. NABCs are good because everyone that needs to see it is there. At the same time, they are also very busy running the NABC and not enough time to look at stuff.

Code added to ACBLscore+ so that we could run custom SQL queries to extract all the data needed and automatically export to Excel.

August 2013. Getting frustrated because TFR is a critical path item and no feedback from ACBL.

Wrote up a project plan on how to get TFR implemented. Would be separate timeline for ACBLscore. Could be implemented now. Worked with both ACBLscore and ACBLscore+. This project plan was something ACBL should have written. I estimated it would take about 20 weeks (elapsed). Would probably involve input from about 50 people.

September 2013. Cryptic feedback from ACBL. Spreadsheets good, but should not be a substitute for the current process.

Seems to have a big misunderstanding on the difference between data input (e.g. Excel not ACBLscore) and the data output (can be in whatever format they wanted).

September 27 2013. Waiting to find the best person to talk to at ACBL. Needs to be one point of contact (POC) not several as mixed messages.

October 21, 2013. No feedback. 3 week delay. Nothing happening at ACBL.

October 2013. “TDs too old for Excel.”

November 2013. TFR rewritten in ACBLscore+.

December 2013. Delivered prototype TFR UI. Wanted feedback. Dec 10. Demoed.

Jan 15, 2014. Still no feedback.

Feb 17, 2014 Outcome of meetings with ACBL is that it is unclear where is the best place for TFR: Acbl web site, ACBLscore+, TTRax (Tourney Traxs), standalone utility. My view is that a stand-alone utility (i.e. Excel) is still best. It can be integrated easily with TTrax.

Original contract wording:
“The software shall support the same tournament financial reporting that is supported in the current version of ACBLscore. This is defined as support for the same data that is transferred at the end of each tournament, but not necessarily in the same format.
There is no requirement to have the same look and feel as the current version, simply the ability to transfer, at a minimum, the same information from the club/tournament to ACBL HQ.”

ACBL could not decide the UI or the format.

ACBL sent a requirement for additional features in the format, data in an uncompressed Excel file format (xlsx) but to not use Excel. But this was sent several months after the work was done.

Can't use Excel.

Must write code that is as good as Excel, that does what Excel does, but runs from within the scoring program, using similar screens to what we have now.

We did that (!), despite the fact that Excel probably has had $100M invested in it.

When we got to the second CR (i.e. third request at writing it after getting agreement on the first two proposals), I said no more work on TFR without a CR. And the CR needs to define exactly what ACBL wants.

This was the biggest problem with TFR, there was not a single person at ACBL who knew the process from start to finish and how the data flowed, and why.

Dec. 21, 2014
Nicolas Hammond edited this comment Dec. 25, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
PBN is probably your best choice.

In ACBLscore, it tracks who played who, which boards, and the table result. It does not track bidding, or play.

The board result may be different than the initial table result (director ruling).

BWS (Bridgemate files) can track bidding and play. That feature is almost never used in ACBLland.

Hand records are separate. They are not stored in ACBLscore. HND or DUP format is common.

Analysis of a hand should probably be a separate thread.
Dec. 21, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
ACBL has a legacy database system on which all of the masterpoint records/member profiles are stored. Surrounding that DB is lots of custom code/scripts to access the data. I believe most of it is RPG. There is also an interface, sort of, for the web access. This is a little more complicated. Details not needed here. All of this is used by customer support/clubs/financials/management etc.

Doing regular backups is part of typical maintenance.

Changing their legacy database, or hardware, RAM or hard drives, is all expensive stuff. Even the annual maintenance of the software is expensive. But this is a legacy system. Well supported by an in-house team.

You can assume that there are separate functions/DB/systems for accounting, HR etc. Typical corporate stuff.

Though it all sounds easy to replace, it's not.

These are legacy databases, legacy systems.

Let me give you one example, let's assume that this is apocryphal.

The field to hold your telephone number was 10 characters. Then they wanted your home and work so it become 20 characters (not two separate fields) with 1-10 your home, 11-20 your work. To write your work number, they take the home number and write additional characters at the end of the string. In the code, the telephone field is only 10 characters long. In the DB, it is now 20. There was no need to change the underlying code of a 10 char limit, because there was a “feature” in the original DB code that allows you to write beyond the limit of the text string and it automatically over-wrote the next value in the DB. In other words, it relies that the data will be stored sequentially on the disk. This “feature” was used extensively with other fields. Modern programmers may scoff at this notion or recoil in terror, but, that's the way certain things were done. Now you have thousands of lines of legacy code, that makes use of this “feature” from years ago. You would have to go through 30+ years of code and re-write all scripts that handle “telephone”, then debug and test. Only now would you be ready to move to a new DB system. Or, you can keep going as you are and as/when there is time available start to get rid of legacy code. Oh, now we also need foreign telephone numbers, so these are somewhere between 10 and 20 characters.

So… as an outsider, it's easy to say, just do blah/blah/blah. However when you look at it, “it's complicated”.

I had a developer working on ACBLscore+. Sharp guy. Every time I'd explain a problem, he'd said, “that's easy, just do xyz”. I said that's fine, but we also need to handle situations a/b/c. Ah! Hadn't thought about that, he'd said, or more likely, “are you serious? This is what they do?” Almost every project he worked on started out with “that's easy” to the standing joke being, “it's complicated”. It became a buzz phrase for the project, ‘it’s complicated".

Tape drives are likely to stay around for a while. There is comfort in being able to see your backup and the hardware to restore.

I've been fortunate to have had a tour of the ACBL data facility, and know some of the internal workings. Efficient backup/restore of critical DB systems is high priority as well as good Disaster Recovery (DR) scenarios (floods).
Dec. 21, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
ACBL Live also includes the “Fast Results” concept of email/text.

This is probably worth a separate discussion.

There were teething problems with this in Providence as well.

But I think most of these have been reported to folks at ACBL. They really need a modern front end support system so these bugs only get reported once.
Dec. 21, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
A standard game file format is difficult.

ACBLscore has its game file. It's proprietary format. It allows them to change it easily without any problems.

There is an XML version of this game file. This was part of the work for ACBLscore+. We have tools that can read a game file and generate XML. Great news is that we can also go the other way, we can take an XML file and generate a game file from it. This is incredibly useful for backwards compatibility. Having an external tool (the tool is called ‘gf’ for game file - written in C, runs on Windows, Linux, Mac) is great for fast results, etc. etc. ACBL don't want to release this tool because it allows access to their internal data. This is how we use Bridgescore+ to create game files that can be read by ACBLscore.

The UK has its own XML format - USEBIO. It works for the UK. It would not handle all the various game files over here. Its structure is different and inconsistent with the ACBLscore view of the world.

The WBF has its own XML format. This is mostly driven by TV/Broadcast requirements. It would not work well in ACBLland.

Ideally the WBF should chair a committee to create a “standard” XML file format. But there is little initiative at that level. (I tried a couple of years ago). It needs someone to drive it, someone that could understand the different requirements in different countries. At the time I suggested it, I was probably the most qualified, but this would not have been helpful for ACBLscore+ work so I did not volunteer myself.

Bridgescore+ has its own XML file format.

There are various documents that were created during the ACBLscore+ work that would be helpful. I'm not sure what ACBL would agree to release. There are a couple that come to mind that would be very useful.

To give an example. A Bridge Event is logically

Event->
Session ->
Section (or Bracket) ->
Team

In ACBLscore, this is not the case. Its game file does not have a hierarchical relationship between, say, Bracket 1 and Bracket 2 of a KO. These are separate events in ACBLscore.


We _could_ have a separate XML that is minimal. (Bridgescore+ has this, at some point I probably should publish a sample XML file showing how everything is structured).

There are other ‘standards’. PBN is the probably the closest. But this doesn't have all the wealth of information needed to recreate an ACBLscore game file. BBO has LIN.

Coming up with a XML file format for a single hand is one level. PBN/LIN does this. But being able to wrap all the XML needed for a tournament on top of this is the harder part.

There are several tools out there for PBN processing.


Dec. 21, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
There is no need for clubs to update their systems.

This is a myth perpetuated by ACBL to attempt to give reasons why ACBLscore+ was being dropped.

See https://www.youtube.com/watch?v=JHnLURIKHmQ
This is a 2Gb Windows XP system running Bridgescore+ (ACBLscore+).
I haven't tried on smaller RAM, but think it should work. It does require a download of the latest Chrome or Firefox (the last version of Internet Explorer that Microsoft supported on XP will not work - same with lots of other web based software).

One of the goals for ACBLscore+ was to run on legacy systems, including XP.
Dec. 21, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
There are lots of little bugs/nits, but this should be expected as Adam pointed out. It is new software.

Here's some more:

http://live.acbl.org/
Select Providence
Select Dec 07, 2014 Swiss/KO (10:00 AM)
Select Riba Brkted B Teams 1

You only get Bracket 1. Not any of the others.

https://web3.acbl.org/acbl-results/game-results/events/NABC143?date=ALL
shows all 10 brackets.

On the last link, click on Bracket 10, Results.
It only shows the top 3 teams.
These get overalls, but other teams get match awards.

Click on Recaps (for Bracket 10).
Now it shows all 7 teams, but the score fields don't make any sense.
The winner, according to this page, is team 3, but their score is 4.0.
Team 1 has a score of 27.0. But won no MPs.
I suspect this is a simple bug between VP won and matches won.
The screen has an option to select NS/EW as a direction.
But this is a bracketed Swiss event.
Makes no sense to select direction.
You can only select Section 20 (which is bracket 10), not see the other brackets.
(This is from the design of ACBLscore where each bracket is actually a separate event,
not a section within the same event - each bracket has a different event code).

There are no hand records for the final day Swiss (top placed teams played pre-dup-ed hands).

The personal scorecards (pick any pair event) are a good start. But nowhere near the quality or sophistication of some of the better tools in ACBLland, e.g. ACBLmerge, but a step in the right direction.

If it is a pairs event, and scored across multiple sections, then the board display will only show results in that section, not the other sections.
e.g.
https://web3.acbl.org/acbl-results/game-results/events/NABC143/0703/2/T/board?board_num=3
Only shows results from section T, it does not include section S (looks like S and T were scored together).

I am glad they got rid of medieval fonts (letters with different sizes) for display. (They do read Bridgewinners!)

These are all little nits. It takes time to produce a good quality output. ACBL are moving in the right direction. It would be nice if they had a support web site where you could post issues like this and they could be quietly fixed. Bridgewinners is probably not the best place.
Dec. 21, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
If I understand correctly, ACBL introduced an MVC model for the interactive part of its web site some time ago. I believe that this happened after they saw how ACBLscore+ was structured. They are using a PHP backend, JQuery. ACBLscore+ was similar, except Ruby/JQuery. PHP/Ruby are similar (I don't want to get into a religious discussion on the merits of each - they are both modern languages - there are advantages/disadvantage to each).
Dec. 21, 2014
.

Bottom Home Top