Join Bridge Winners
All comments by Nicolas Hammond
You are ignoring the author of this comment. Click to temporarily show the comment.
Lots of fair questions. I'll try to answer some real quick, but tired fingers and Gatlinburg looming on the horizon. Remind me after Gatlinburg (and the week of recovery from Gatlinburg) and I'll try and get you a more detailed response.

1) It's more than just Copyright. The underlying technology behind ACBLscore+ is a great product. I've put far more hours during the ACBLscore+ contract than I was supposed to because there are benefits to my company to be able to use this underlying technology for other customers (and we have). Cuts some development time by a factor of 10x or greater.

2) Will answer after G.

3) My output ratio is quite high; every programmer has a different efficiency level. Bluntly ACBL were very lucky to find Jim. He did everything. I've come close; done a lot of the code. But you have to find someone who understands Bridge, movements, Swiss, finances, scoring. I out-sourced a lot of this; but was quite brutal with letting people go if they didn't perform. Jim is a tough act to replace.

4) Congratulations on getting your hands on the contract. I know that someone was pursuing this with ACBL. I just didn't know who.

In basic terms, replicate ACBLscore. The macro function was explicitly excluded. We do have something similar with ACBLscore+; there's a CLI, but not something you would expose to a CD or TD it's more for developers. But it's very powerful.

5) Basically fixed price; fixed time. Per phase so they could fire us if we weren't delivering (I think I added that clause to the contract). We assumed the requirements would come; same as I assumed I could hire the right programmers that could do the work. I got lucky. Found some great ones.

I wanted to put ACBLscore+ in the hands of some clubs about a year into the contract. ACBL said no. Back then the plan was clubs first, then tournaments. Plan since revised. Do tournaments first, train the TDs. Turns out that lots of ACBL TDs are the first line of support for local clubs - we didn't know that at the time (neither did ACBL).

The contract had phases; so arguably each was a deadline. By end of Phase 3 we were under-time, under-budget. Per contract, money saved was not to be applied to next phase. Phase 4 is when we started needing specs from ACBL.

6) I always claimed that long term ACBLscore+ would save money. Now the tricky part. For who?

We'll know a lot more about numbers after Gatlinburg.

But let's say I can start an event with 8 TDs, not 13. (Am thinking the large KOs). So we “save” 5 TD sessions, at say $160/session. That's $800 per session. (2 per day for 5 days at Gatlinburg). But although that's a saving, it's not for ACBL. It's less income. TDs are salaried. So saving money doesn't help ACBL. It helps the Sponsor, but not ACBL.

Using funny money: Gatlinburg KOs can have 20 brackets. 320 teams. 1300 players. (I'm rounding). Typically they start 25 minutes after game time (that's the time that the last team is posted in the rack). Let's say we do it in 10 minutes. We have ‘saved’ 1300/4=325 hours of players having to wait.

7) After Gatlinburg.

Also need to figure in training costs/support costs. ACBLscore is hard to learn. ACBLscore+ is different to learn.

8) I've put quite a bit of time and $$ into Bridgescore+, as have others, because I believe in it. Have to give full answer after Gatlinburg.


The biggest benefit won't be version 1.0 of whatever product is delivered. It will be version 2.0. For those who have played in other parts of the world ACBL is a technology backwater. This will leapfrog even what WBF and what the rest of the world has.

Making TDs more technology aware, more efficient will help all of us. There is so much more that can be done with Bridge and data that we are only just scratching the surface with ACBLscore+.

Things that ACBL has waited on for years - more than 3 strats in a pairs game, integrated results, electronic scoring devices (Bridgemates/Bridgepads) tied into the scoring program for team games. This is all easy with open software.

Even some of the $600K laundry list that ACBL was going to spend (since cut back to $130K) was so easy that I wrote some in a couple of days and posted on the Internet (for free). That's the benefit of new technology. It's much easier to add new features. That's a major cost saving. Supporting it is much easier as well (look at the recent masterpoint change fiasco).

I guess offering ACBL a fixed-price, no-pay-until-complete offer is a possibility, or something with defined deliverables and partial payments and assuming no specs required from ACBL, but this can wait until after Gatlinburg.

Probably haven't answered all your questions; remind me about 10 days after Gatlinburg.


April 8, 2015
Nicolas Hammond edited this comment April 8, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Ironically probably at the point where the various developers that were on the project are now further along and we don't need all the specs.

The missing specs included movements. In talking with the guy who did most of this code (he lurks on this site, never posts), it's still a 5-7 month project. He's part time. Got to finish integrating the movement code into the UI. That's tricky. We recently (this week!) did some work with Bridgemates/movements. The problem for us is a lot better understood than 18 months ago. Getting the specs from ACBL would help the process; but we now have sufficient information to probably get this done without any more help from ACBL. May need a little help from some of the very experienced TDs. EDMOV is still a challenge; but it's a UI challenge, not a technical challenge. (Despite what Ralph posted, we actually have a developer EDMOV functionality so that we could test scoring with different movements, but it is not something that should not see the light of day).

Masterpoints was also missing specs. Not the calculations, but the assignment and eligibility. You've all seen the mess with the release of new masterpoints at the start of this year and this was just with calculations.

The problem with the calculations is that the published specs (Tech Files, ACBL web sites) are not what is implemented in ACBLscore. So you either implement the specs, or what ACBLscore has done. We did a bit of both. Originally I thought that ACBLscore+ should match the MPs from ACBLscore. My opinion now is that if we are within 0.01, or some other small tolerance, I don't care. The rounding used within ACBLscore is so obtuse, not documented in any specs, that it should not be replicated. In some parts of ACBLscore+ we did replicate and it's simply wrong. Round, then multiply by a large number, then round again. No. We don't need to be constrained by 8 bit math functions.

For 2015 there are new formula, so we have some code to write. But it should not be too much. There's some UI change (club calculations are different), but it's mostly table driven so won't be too hard.

The largest missing spec was assignments/eligibility. This was never delivered. It is probably only a 2-5 page document but somewhere there needs to be a list of all the rules for assignment/eligibility. The only way we would find them is to compare a game file from ACBLscore to ACBLscore+, look at the differences and then back-track for the reasons why. This is not the best way of coding.

We probably spent 10x my original estimate of the work needed for masterpoints during the contract.

Some of the other missings specs were really change requests (CR). For example how tournament financials are done.

But if you were to take a practical approach for ACBLscore+ you would create a minimum set of functionality, roll it out, add the missing functionality. For example, if you can create an ACBLscore game file from ACBLscore+ (you can), then you can use the existing club and tournament financials so you would not need financials in the first roll-out. That's a pragmatic approach to a release. My suggestion is at http://bsp.bridgescoreplus.com/?page_id=44
I wrote that back in September 2014. Still true today.

Because of some of the recent work we have done, I'm even more optimistic about release dates. I'm going to assume that we go from Bridgescore+ because that has a lot more testing/bug fixes/features than ACBLscore+. The only remaining challenges are releasing the product, there are no real hard technical problems to solve.

Someone had asked about how difficult it would be to install on Windows. Answer is download two products: Postgres (as the DB), Rails (as the engine) and then ACBLscore+ as a zip file, unzip it, and you are ready to go. When I talked to Greg, I estimated that Bridgemate code in ACBLscore+ was 0-2 weeks of work; I've spent some of this week working with the guy who did the code for ACBLscore+ and the version that is in ACBLscore+ worked, but we've spent a couple of days this week making it much more efficient and robust.
April 8, 2015
Nicolas Hammond edited this comment April 8, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
The external technology committee members haven't really spent much time with ACBLscore+ with the exception of Greg. Remember neither Greg, Uday know anything about what ACBLscore does. I believe Ralph is a part-time club director. It is incomplete with respect to the contract - I'm the one that told them that (!) as is well documented in the monthly status reports that they have access to. None of them is a full time TD and so really aren't qualified to judge on what's there or not. (For example: Greg/Uday thought club and tournament finances were the same). The best test is going to be to have me run a tournament in parallel with some experienced TDs. Same with club games. Putting ACBLscore+ in the hands of someone who doesn't know what it can do is like asking a car driver to fly a plane.

I only know what Bob Heller (D7 DD) has posted about the prototype. I think it was an attempt to disprove the “personal web server” approach. It failed (apparently). I think it was $100K spent to find a technical reason why ACBLscore+ should not be released to cover up the real reason.

The contract was a time-limited, $$-limited contract. My constant refrain: anything that didn't have a documented 3+ month delay or a dependency on a 3+ month delay was done. ACBL took responsibility for those delays. The project was going to run out of one or the other first. Remember: ACBL came back and paid even more money when the we terminated the contract. I'm struggling for a good reason why other than the PR by saying they terminated it.

It is not the tech committee's assessment that ACBLscore+ is 18 months away, that's a number I gave to Greg/Uday! Greg wasn't paying close attention on the phone call (see previous posts). I gave him a range of time, and range of very vague numbers. There's elapsed time, developer man months. Want shortest delivery - we are looking at 5-7 months; a critical path item was delayed by about 6 months during the contract. Doesn't matter how many programmers you throw at it. Want cheapest: just use 1 programmer to finish it off. Want most cost-efficient: I estimated 9-18 months. Wide range. Depends on who does the work. Perhaps it's not me. Someone from within ACBL needs to get trained to take over the support. Want realistic: 6-12 months BUT we roll out tomorrow!!! i.e. we put ACBLscore+ in use starting on day 1. Start the training. Roll out ACBLscore+ now, have it run KOs, then take over Swiss. Pairs game the last. Club finances/tournament finances are independent.

So… let's use the number of 6-9 months NOT 18 months for completion. I'll assume I can re-hire the programmers that were working on it before. Won't need all of them.

If I were to use ACBL Live as my benchmark for quality of code/testing done before a release, then I would have wanted to release ACBLscore+ about 3 months before the end of the contract.

Remember: the version they have was in use in Gatlinburg last year. It is ready for production. Not all of it. But start to get TDs used to it. The biggest elapsed time factor for a successful release is the feedback from TDs. That's what is going to take the time, not the developers to finish the code.

You have to remember that it takes time rolling out any software to the field. ACBLscore+ is highly customized software, several man years of development. It needs field-testing. If I were in charge of ACBL, and knowing what I know about ACBLscore+, I'd release what is there now, limited release to a select group of TDs, get them to find the kinks, provide useful feedback.

Even if ACBLscore+ was a totally finished, bug free product right now, I would estimate it would take 6-12 months to roll it out.

Your guess is as good as mine why they paid more at the end. Either they wanted to be able to say that they terminated the contract, or they wanted the code used in Gatlinburg. Probably wouldn't look good to say contract ended in March 2014, but then they didn't have the code used in Gatlinburg. I don't know. All I know it was a strange decision back then. I assumed that they were going to continue to work on it in-house so cheaper to pay me for the code that was done and the testing rather than do it themselves.
April 8, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Coding hours? Total hours? Does writing on Bridgewinners count? Even the one character posts?

There's more than just me; I may be the public face, but there is more than just me working on Bridgescore+.

The longest total time is going to tournaments and running it, if you exclude phone calls/emails with Greg. Each time at a tournament is more feedback; improve the UI. Small, subtle changes but makes for a better product. Total time is much more than the coding time. Even creating videos which is useful for training is part of total time on the project. There are actual some people using Bridgescore+ at tournaments so there's support time as well.

Over the last 2-3 weeks we (remember there is more than just me) have found out about some of the ‘complaints’ with ACBLscore+.

“Doesn't run on latest Windows (8.1)”. Took a few hours (less than 2 man days), but now running on Windows 8.1 - download/install Postgres, download/install Rails, download ACBLscore+ as a Zip file. Unzip. Run ACBLscore+. Three step process. So ACBLscore+ runs on XP, Windows 7, Mac, Linux.

Even got it installed in a Windows 8.1 Virtual Box that ran on Mac & Windows and could be downloaded from the Internet. 25Gb image; only uses 15Gb; ran/tested in a 2Gb Virtual Box.

“How long to finish Bridgemates?” I estimated 1-2 weeks; took a couple of days. Actually the code we had worked in ACBLscore+, we had not tested in for 12+ months. I just wanted a better quality API so took some time to write/test JSON interface to upload BWS names/scores to Bridgescore+. Also added more test suites so we could separately test the JSON output.

I haven't added up all the time; I'd have to ask the others that are working on it and add up the time.

I've posted previously the difference in output ratio of different programmers; so elapsed time for the group I have would be different than others doing the work.

Probably not the exact answer you wanted; we used to do all the tracking for hours for ACBL but no need since the contract ended.
April 8, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Kevin:

They were getting a ‘complete’ product from us; however in order to finish the product they needed to deliver the items that they said they would deliver during the contract. Not just the specs, but there was 3 man years of work they were supposed to do during the contract.

BTW, I have never claimed ACBLscore+ is ‘complete’; what I have said is that it is ready for roll-out, start being used, use the TD feedback time to complete the software development, do both tasks in parallel.
April 8, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
It took 5 months of negotiation….

It was back/forth; it wasn't really contentious. ACBL knew at a high level what they wanted (replace ACBLscore), I knew what we could deliver within certain time periods. Rest of the stuff was making sure that the lawyers were happy and that there was contingencies for either party if anything went wrong. Fairly standard stuff. Nothing unusual.

Looks like ACBL did not use outside counsel to make sure that they knew what they signed. They did get a 10% break in price for giving up licensing rights.
April 8, 2015
Nicolas Hammond edited this comment April 8, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
I answered that question earlier in this thread.

It is possible that ACBL have hired new outside counsel that has given them a different answer.

Either way, ask the BOD to get all the outside counsel opinions - it's something that they should be able to see anyway as it affects all ACBL technology; not just ACBLscore+.
April 8, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
The contract did not require full payment.

There was an opt-out clause for ACBL. ACBL could terminate with or without cause at the completion of any phase of the project with 15 days written notice. ACBL could terminate if HS failed to deliver any of the phases on time with 15 days written notice.

Either party could terminate: “Either party may terminate this Agreement in event of an uncured material breach of this Agreement after providing thirty (30) calendar days written notice of such breach to the breaching party and such breach remains uncured for an additional thirty (30) calendar days. For the purposes of this Agreement, a “material breach” shall be defined as a breach which is substantial, destroys the value of the Agreement and operates to excuse further performance by the aggrieved party.”

I have previously mentioned unpaid invoices, missing specs etc.

ACBL were aware of these problems (!).

On January 16, 2014, I sent Robert Hartman, an 11 page letter detailing substantial breaches. There was a supporting 20 page document that listed all the problems in more technical details. I had told my contact at ACBL that this was coming as the list of problems was getting longer, there was little to no follow through and no sense of any urgency.

ACBL had 60 days to fix. They didn't.

We “mutually agreed” (if that's the right word) that March 31, 2014 would be the last day of the contract. We had done all that we could that didn't have a 3+ month delay from ACBL, or was dependent on something that had a documented 3+ month delay from ACBL (we had to start doing CYA about a year into the contract). Doing more work on ACBLscore+ would not be a cost-efficient approach given the fact that there were too many things waiting on missing specs. Better to get the specs done, then restart the work. There was a mutual termination clause in the contract. Using that wording would sound a lot better for ACBL than the real reason so that was the ‘official’ response. We invoiced them for March 2014. We sent a final monthly status report. The March 31, 2014 status report stated that the contract is over and that this was the final status report. Per request from ACBL management this status report was only sent to two people with ACBL (Robert + one other). Management did not want the status reports to be sent to others (for the first 18 months or so of the contract the general status report went to all developers, and some people on the BOD). ACBL Management asked me to stop sending the status reports to the BOD sometime around mid/late 2013 when the list of issues was obvious.

During March 2014, we made sure all code was available for ACBL to download and I worked with an ACBL contractor so that they could start working on this internally as ultimately they would be supporting it.

During March 2014, we (ACBL/HS) also started working on a new contract as there was still work to be done for ACBLscore+. (The 3+ month list of items).

From April 1, 2014, the code that we developed was owned by HS, not ACBL. We ran ACBLscore+, including some changes post April 1, 2014, in Gatlinburg. Note that a lot of this code was outside the scope of the original ACBLscore+ work, but was something I wanted to do to help run events at Gatlinburg (and other tournaments).

ACBL wanted that code, they posted great things about it on their Facebook page (since deleted).

ACBL asked to change the contract end date to be May 29. They would pay for the code from April 1 to the code developed through May 29. That was the required 15 day notice, they told me May 14. The stated reason was “ there have been many conversations with outside counsel regarding the need to protect our ability to copyright ACBLscore+.” and “Should you not agree to this wording, we will forced to terminate the original agreement. ” The wording I have previously mentioned was regarding the Work-For-Hire clause and the copyright. I'm a businessman at heart; but also want to see what's best for Bridge - the code in Gatlinburg was much better than March 31 delivery because it had some real world testing (which is what the code was ready for). So I agreed. Invoiced them, they paid. ACBL could now claim that they “terminated the contract”. However they had now paid in full, they also ‘terminated the contract’ which meant that they did not want me available for any support questions. So they had all this code, hadn't bothered during 2 years to find out how it all worked, now didn't want any support (contractually it was up to 10 hours per month for the next 12 months but use of the 10 hours per month was up to ACBL and they were only to be billed if any hours used).

In effective, the only thing they “terminated” was the ability to get support on the product they had paid for. And they didn't have to use that support if they didn't want to. That made no sense. But they had a huge marketing problem on their hands - management had negotiated a contract for software that their new lawyers had told them not to use.

So….

1. HS terminated the contract (60 day notice to fix effective Jan 16, 2014).

2. Contract was mutually terminated (March 31, 2014).

3. Contract ended (all deliveries done, full payment of contract), (May 2014) (Excluding those items that had the 3+ month delay or dependent items).

4. ACBL cancelled the contract (May 29, 2014).

All are correct answers. Pick whichever one fits your version of what happened.
April 8, 2015
Nicolas Hammond edited this comment April 8, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
I watched that clip.

Absolutely correct. “We have the rights to use” is what Robert Hartman said. He is correct.

Having the rights to use, and using them are totally different :-)

The ACBL OC told them, “(copyright) is necessary to provide you (ACBL) protection…”.

The ACBLscore+ was not a Work-For-Hire contract. Copyright resides with the original developer, in this case Hammond Software. We negotiated rights to the code, at the same time ACBL got a 10% discount on the work. ACBL wanted my company to give up all rights to the code, and to all derivative work on re-using the code, for nothing in return. We said no. So ACBL on May 2, 2014, “reach(ed) out to Counsel on(sic) last time” to see if “(ACBL) had any flexibility”. OC said no. So we were told (May 2, 2014) if “(Hammond Software) did not agree to this wording, (ACBL) will be forced to terminate the original agreement”. We did not agree (why would we?). ACBL was “forced to terminate” (which makes no sense because the contract was over). The rest is history.

If you listen to the clip, just before that Greg is talking about a utility from ACBLscore+ that we called gfprint (or ‘gf’). It was something we wrote that does Fast Results (among many other things). ACBL has completely re-written their own version, at an undisclosed cost. You will hear Greg mention that. The only reason they have done this is the copyright issue. ACBL had Fast Results 3+ years ago from the ACBLscore+ project but never rolled it out themselves.

I keep saying that the BOD should hire an independent counsel to investigate. ACBL are re-inventing the wheel, only they seem to be creating square wheels out of round ones.

Management are going from their OC advice. I don't think that the Board is aware of this advice.

Management still hasn't asked for a demo of what ACBLscore+ can do. I've offered to run it (for free) at the last 2 nationals to help with starting KOs, running the Swiss, but they have declined. Earlier this year when I made the offer to help start the KOs/running Swiss in New Orleans, they didn't even know that they had this code!

So… they have this code… but a lawyer has told them not to use it in order to protect the ACBL. Go figure.

April 7, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
This is not ridiculous. It is the ACBL reason for throwing away ACBLscore+.

If you happen to be a US-based expert lawyer that works in this area, please let us know.

The copyright issue was the stated reason that ACBL gave me (May 2014, though this started around September/October 2013) for being “forced to terminate the original agreement.” I am still not sure what reason ACBL is giving you for throwing away ACBLscore+.

See my post on http://bridgewinners.com/article/view/whos-supervising-whom/
that starts, ”The ACBLscore+ fiasco is very simple.“ for more detailed information/dates etc.

Summarizing: ACBL has legal opinion from ”outside counsel, who is an expert in such areas“ that they need the copyright. Their OC also gave ACBL the legal rationale for wanting/needing this.

I have to assume that Robert and Peter Rank (ACBL league counsel) have informed the Board. They should have done so prior to November 2013. I also assume that they told the board that they were withholding payment to my company at that time to try to negotiate for the copyright (aka ”work-for-hire" within ACBL). As the board presumably approved the original contract no-one in management or the Board wants to investigate.
April 7, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
D7 has coupons.

Tap and Pay is not common in US. I have looked at some NFC stuff. But that's a year or so away as few users in the US at the moment.

We have to go from “I want an easy way to pay” to being able to look at the entire ACBL environment and see how it can be integrated easily. Remember that the problems are always in the exceptions so figuring out how to do refunds/avoid double charging etc. etc. are all the types of practical things to consider for a roll out.
April 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
I'm in D7. They introduced coupons last year. No need for me to get involved. We are still learning the numbers and how they will play out.

Having TDs accept a CC entry is a lot harder. They have to have CC processing machines, know how to use them, then know how to tie an entry to a particular event (session) because of how ACBL's tournament finances work. I did (briefly) look at it during ACBLscore+ but it was out of scope (not in Contract), but I satisfied myself that we could do it by integrating Square or something like that and making sure that ACBLscore+ had the appropriate APIs or ability to easily add the APIs for when the time came.

With the current process, accepting CCs is a harder to integrate into the overall system. Just telling you how it is; conceptually to us as players, swipe my card and I'm done. Backend processing is a little more difficult. Harder for me to come up with a good integration within the limits of the existing system (ACBLscore).

Advanced entries is what we will have in Gatlinburg. It's going to be limited because TDs need to see the benefits. The Gatlinburg DIC is being great about new technology, but at the same time I can't overwhelm him and the TDs with lots of new stuff. And we have to make sure it works, and is supported. This is “Live”, it has to work first time.
April 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Brian: play at an tournament that has 10/3 scheduling as well as 9/1:30, e.g. some NABCs, some regionals.

Lose in the 10am KO, you'll normally finish around 1pm. Got 30 minutes to decide if you play in a 3pm event or try and play in the 1:30pm event for one session so you can get home sooner.

The current scheduling accommodates all types of players. I doubt there will be changes to the upcoming schedules for tournaments.

Ross: I'm proposing solutions to your problem. Offer as much flexibility as is reasonable. Will demo in Gatlinburg. If it works, hopefully will percolate to other ACBL tournaments. Some of what we will be doing is not technology based, but a change in the process or the way that ACBL TDs are used to working.
April 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
In ACBL land, you may not know which event you are going to play in one hour before start time. If you are in a KO, that may lose, sometimes you may only have 30 minutes before the next event starts. Now go to decide if playing in another KO, or with different team mates, or a Swiss, or break the team and play Pairs.

There no reason to give up on the flexibility that ACBL currently offers.
April 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Depends on the size of your Unit. My unit (114) was over 3200 members until we recently split. There are Units in Florida that are even bigger.

Instead of using CC at the time of entry purchase, you sell $20 coupons that can be used for entry instead of cash. Same as Bridgebucks at NABC.

Although you (Unit/District) incur a credit card processing cost; you save because the TDs need to make fewer trips to the bank (the DIC should be charging you TD time for a bank delivery though not all do). You also save because inevitably someone loses the $20 coupon, or they die. No-one has published the metrics on what these numbers are. It would be useful information.

You do need to make sure that the Bridgebucks (or equivalent) are monotonically numbered to prevent photocopy fraud. You can use more expensive paper to avoid fraud. You can outsource the production (D7 has done that).

There are some accounting issues.

You need to make sure that all coupons are time-limited, i.e. expire 2-3 years in the future else there are even more accounting issues.

==

The information that the DIC provides to the Sponsor varies.

The default is the Tournament Financial data from ACBLscore.

It's terse. It's limited. There are lots of problems. Often there are not fields for a certain type of expense so something will get mis-labeled. There is no tracking of 1099 information (if your District/Unit is large enough to have to pay for caddy 1099 at end of year). Trying to track the cash payments to a specific caddy can be hard if you need to give them a 1099 at the end of the year.

The information is usually in a hard copy report. You have to manually re-enter into your Unit/District financial package.

Most Units are small enough, same with some Districts that the issues I have raised are moot.

Others are not.

I have spent a lot of time at Sectionals/Regionals/NABCs/clubs. They are all different.

Hopefully explained the reasons why some Districts are doing things differently.

What works for your Unit/District may not work elsewhere.
April 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Yes.

ACBLscore can only accept input from either the KeyBoard/Mouse or through BridgeMates.

There is an ability for importing CSV data, but then typically is when moving data from one ACBLscore section to another; it's not really a viable interface for NABC+ events.

There are a couple of other ways.

You could create an AutoHotKey macro, or use ‘gf’. ‘gf’ is a tool delivered to ACBL as part of the ACBLscore+ project. It can read/write ACBLscore game files, it can read/write XML. So you could create an XML file, use ‘gf’ to create an ACBLscore game file and use that. It's what we use for ACBLscore+/Bridgescore+ testing. When running in parallel, Score+ can create an ACBLscore game file at any time, e.g. before name entry, after name entry, during scoring, after event etc. etc.

April 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
“Star Chamber” is the term that the BOD use. I had an ACBL member (no names given) tell me in New Orleans that a BOD member had to go to the “Star Chamber”, not sure who it was. One of the charges was “talking to me”. I had the Star Chamber incident confirmed by a BOD member (who wishes to remain anonymous).

I also heard, but have not been able to confirm, that a similar incident happened last year, i.e. a BOD member had to go in front of the Star Chamber.

Obviously all Star Chamber hearings are supposed to be confidential. However sometimes information leaks.

Ask your DD if someone had to go in front of the Star Chamber in New Orleans. Ask if “talking to me” was one of the charges. Not sure they can even confirm if anyone was charged.

I believe it is a member, not a BOD member, based on what I've heard. Apparently a member of an organization can request certain things from a Non Profit. ACBL is registered in the State of New York. So New York law applies.
April 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
It is a cultural thing; ACBL members expect to pay up until game time (at some times shortly afterwards!). ACBL TDs are trained for customer service, so take entries up to the last minute possible.

First, some explanations to your questions (based on my observations):

1. Easier for TDs to track. They have to account for money for each event (actually each session within an event).
2. See #1.
3. See #1.
4. Some sponsors (e.g. Districts/Units do that). Typically only the larger ones.
5. Well-known problem. They prefer it not be discussed or widely known.
6. Computers at ACBL events are not connected, not networked.
So the computer running the event has no idea if you are paid or not.
This will take some time to fix.
7. Some problem with a cashier closing out a till.
The answer is usually. If not, the TD has to figure out why.
Usually it's a forgotten free play, or a comp.
Rarely it can be given a $10 bill for change instead of $1. These things happen.

Now…. expecting to pay up to the last minute does not negate the other suggestions you have for Regionals.

Not surprisingly, I have some metrics:

At a NABC, the best TDs can process an entry in around 6 seconds. On average. Take your money, give you an entry slip, move on to the next customer. Cash is fast. Taking CCs is slow. Obviously requiring everyone to show up 30 minutes before game time to pay creates the crush of taking cash at last minute.

To give you metrics on credit card sales - see the line for the Bridgebucks at a NABC and how slowly it goes. Can take 30-60 seconds per transaction.

“Bums in seats”. TDs want to start events quickly. For a pair events, they need to know how many pairs are there. All sales within 30 minutes means the DIC knows exactly how many entries are sold (usually!!) and more importantly that the entrants are there. So they can configure the pair sections accordingly. Swiss is a little different; you are normally assigned round 1. Bracketed KOs are different again. In all cases, they need to know “bums in seats”.

TDs will tell you that teams (a team can be two people if a pair event) not showing up causes them lots of grief. They may over-exaggerate a little, but it makes their job easier if they know the number of bums in seats. Someone buying an entry early, but not showing up, or showing up late, makes the TD's job of running the event smoothly a lot harder.

Next question is obviously who is running the asylum - are we doing this for the benefit of the players, or the TDs. Answer should be both.

The TDs have created the current system/process for registration based on the technology available to them.

On-line registration (Bridgewinners has done some work for NABC+ events) is a start. But currently, because of the back-end technology, all data has to be manually retyped into the scoring system (ACBLscore). Therefore there is some benefit to the players (sign up early) but little or no benefit for the TDs (arguably it's a little extra work for them to handle on-line sales).

Until there is a system in place that easily ties in on-line sales/early sales with the current 30-minute-before-game-time sales, there probably won't be much of a change.

(Before you ask: ACBLscore+ Version 1.0 was designed to be same as ACBLscore, but Version 2.0 would have lots of abilities to receive on-line/pre-registration data so could easily implement on-line sales etc.).

I spent a lot of time looking at various technology issues during the ACBLscore+ work, so there are lots of things that can be done to improve both the player, and the TD, experience, some of which don't involve technology. And also the DIC (ultimately they are responsible for the $$).

We (District 7, me) will be introducing some changes in Gatlinburg. This is the biggest regional by far. Baby steps. Changing the culture/system/process of an organization is not something that is easy. In Gatlinburg, we are going to offer pre-registration (aka early selling). It's not going to be on-line. But we will offer early sales for some events. I have to convince the DIC/TDs that this is a benefit (to them) that will not cost money, but will save money. I have metrics from the last 2 Gatlinburg tournaments so we are going to see if this works. Got to do some TD training, got to do some player education. Assuming this works, it's possible that the TDs/DICs could suggest this to other Districts. I will post more, and separately, later in the week for those that will be playing in Gatlinburg. The more education we can give to the players on a new process, the better and smoother for all involved. There are many other things that we are players simply “do” but we do for the benefit of the current process, there is no reason that we should keep doing what we do.

So… someone is thinking about the problem. Been slowly rolling out some of these changes for testing at Regionals over the last few months. But any new process has to integrate with the existing systems/processes in place but be demonstrably better for the players and TDs.

Stay tuned.


April 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
If you have a DD going to Gatlinburg, let them/me know.

I have always made time to show ACBLscore+/Bridgescore+ to DDs at tournaments that I have run it at. I may not know all of their faces/names, particularly the newer ones, but if they have an interest I will be happy to show them.

Or if there is a designate, let me know.

Best time will be between sessions, not during live production, i.e. not -30 minutes/+ 15 minutes of an event - the TDs are busy starting/running the event and my job is to help them get it done.

They will all be able to see the player's perspective (projector), but I can also show them the TD interface.
April 5, 2015
Nicolas Hammond edited this comment April 5, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
“The one other issue I can think of is licensing. Presumably Hammond Software (HS) has warranted to the ACBL that all the code is properly licensed”

ACBLscore+ uses about 70+ software products from different companies/people/organizations. We had to prepare a detailed list of all the software we used for ACBL, along with links the appropriate license. Most are under the MIT license or BSD or GPL or Apache.

Everything that we used, to the best of our knowledge, has a ‘free to use’ type license.
April 4, 2015
.

Bottom Home Top