ACBLmerge Programming Notes

by Matthew Kidd

After more than two years, I finally released a new version (1.3.4) of ACBLmerge last week. Why the long delay? Lot of reasons. Shortly after the 1.3.3 release I became and continue to be a unit president. Also I had long wanted to write the Payoff Matrix software which in turn required partially reverse engineering the ACBLscore game file format, work that seemed worth taking the time to document. David Bird and Taf Anthias’ pair of books, Winning Notrump Leads (2011) and Winning Suit Contract Leads (2012), motivated me to write the Lead Solver software. In an attempt to learn PHP, I wrote the Alternative Bridge Bulletin viewer, implementing an idea I suggested in a talk at the end of 2011. I’m happy to say the ACBL, despite an initial legal panic, incorporated my idea in their June 2014 website overhaul. Along the way, I worked on several bridge related analysis projects. And I traveled, read a lot, and took photography seriously. I even played a few sessions of bridge.

But more than anything, ACBLscore+ damped my enthusiasm for continuing ACBLmerge development. The announced ACBLscore+ development timeline was about a year. I never believed this because it is difficult to estimate the time required to develop software and there were sure to be many gotchas for a one off project involving a legacy system at the heart of entire organization. Realistically, I figured it would take twice as long but it really did seem like it would happen. The initial ACBLscore+ deliverable was to replicate the existing scoring functionality and also the financial support, the latter critical to the ACBL though mostly unknown to players. My guess was that ACBLscore+ would arrive in two years, ACBLmerge could then be tweaked to read whatever, possibly XML based format, replaced the binary game file format, and a year after that any reporting advantages that ACBLmerge had would by then be incorporated into ACBLscore+.

Accordingly, ACBLmerge seemed to have a three year shelf life. ACBLmerge was fairly mature at this point. It didn’t seem worth implementing support for rare event formats such as individual events or BAM. My biggest fear was that the ACBL would do a good enough job with ACBLscore+ to make using ACBLmerge not worth the effort while failing to implement useful functionality such as the field strength calculation, face view, or masterpoint tooltip. But things never got that far. At the summer 2014 Nationals, the ACBL announced that development of ACBLscore was being discontinued.

Last, but not insignificantly, I had some technical debt. ACBLmerge wasn’t under revision control. Certainly, I knew about revision control, had often used it for business software, indeed had set up the repositories. But ACBLmerge started small. It was just one Perl program and a couple of documentation files. I was the only developer. It wasn’t clear how long the program would remain relevant. And before a project becomes mature, each new version is such an improvement on the last, that one hardly cares about the old versions. Then one day, the project is no longer small. Regressions become more likely and users are strung out across different versions. Working with a code repository, instead of a collection of zip files, one for each release, becomes very advantageous. Before finishing ACBLmerge 1.3.4, I paid off the technical debt. All the versions are now checked into a Subversion repository with meaningful log messages. Even the commit dates are properly backdated so that the repository nearly matches the actual development timeline. Having the project under revision control has already been helpful. And I have the option of setting up a Subversion server, if others want to help with the development.

It appears that ACBLscore and its current game file format are here to stay for awhile. This makes it worth continuing the development of ACBLmerge. It now appears the game file format is understood well enough that a future release of ACBLmerge will be able to read game files directly, generating reports de novo rather than tweaking the existing ACBLscore reports. This approach would save club users a couple of steps and has significant implications for tournament users who could have ACBLmerge HTML results generated for all sections, combined or now, of all events simply by supplying an ACBLscore game file, a hand record file, and optionally one or more electronic scoring (.bws) files.