Whither face-to-face bridge

[hrothgar]

Hi All

 

In my perpetual effort to postpone work on my thesis, I spent some time developing a case study regarding how membership organizations can adapt to technical change.  In this study, I attempted to define a technology strategy that would allow the ACBL to make more effective use of the Internet to serve its members.

 

My presentation focuses on the necessity for the ACBL to find new ways to provide value to its membership base.

 

As always, comments and discussion is more than welcome.

 

The proposal is available in PDF format on my web site.

 

http://web.mit.edu/~rwilley/www/Strategy.pdf

 

My news agent directs followup mail to my hotmail account. Sadly, this account is complete clogged with SPAM, and I sometimes miss "real" emails in this account.

 

The best way to reach me is either posting a followup comment here on the news group.

 

Alternatively, you can sent me an email at my MIT account.

The email address is easy to figure out based on the URL that I provided.

[inquiry]

Hi John,

 

I read  your PDF. A couple of comments.

 

First, I think your put a lot of effort in your document, and it shows. I agree with you that for the vast majority of bridge players, organizations like the ACBL are quickly becoming unimportant.

 

Why was the ACBL important to me in my younger days? I wanted to play serious, competitive bridge. Playing with my mom and her lady friends just didn't cut it. I didn't aspire to be a world champion or even national champion, but I wanted to play against sound, competent opponents. Where could I find such opponents? Why at ACBL sanctioned events of course. The local clubs where I typically played were populated mostly by what would be characterized as beginners or intermediate players. Placing everytime one plays is not exactly challenge in such environments. But at sectional and regional tournments, the class of opponent got much better. Eventually I move

d to larger cities, and even at the local clubs, the competition was challenging.

 

Now with internet bridge, I and others, can find challenging opponents without the hassle of travel and tournment fees. I kibitz a lot and have my own list of who can play and who can not. Now, I can generally find a the bridge competition I seek without leaving home, and I can play for 30 min, an hour, two hours, or however long I like when I HAVE THE TIME.

 

This is very attactive for me. I don't need masterpoints, I have a good picture of my stregnth and weaknesses as a player (and yes, I do have a lot of masterpoints from my much younger days). I don't aspire to be a national or world champion (I don't have the ability for frequent travel, even if I had such aspirations). I just want to play sound, competitve bridge, and I want to learn from my mistakes. The printed hand records from the ACBL tournments  help, but online bridge and Fred's bridgevu software makes it much easier for such  review.

 

The ACBL is also unimportant for the millions of bridge players who just want to play bridge (social players). They certainly have no aspirations of glory they simply want to have fun playing, and online bridge solves their needs easily. Of course a rift occurs at online sites where highly competitive player get at a table with purely social players... but soon enough one or the other leaves the table and finds one more to their liking.

 

I think the computer bridge idea for tournments (replacing cards) is excellent, but come on, even at 650 a pop, that is too expensive. I remember the day when it was rare for the tourment directors to even have a computer for figuring out the matchpoints, much less four computers for every "table". Maybe the ACBL could hold events at centers or colleges with massive computer labs.

 

I am leary of serious on-line tournments (especially for national titles).... the temptation to some people who's ego's can't stand losing would be too great. I can send you the results of one pair from a trivial OKBridge tournment were the bidding and play (picking up pscyhes by their partner 4 for 4, not supporting with 5 card support, unbelievable doubles on dirt and remarkable double dummy opening leads) can only lead to one conclusion..... and that was just a little daily tournment with nothing but OKBridge rating on the line. Not money, not real prestige.

 

I also have to voice that while I love your "hyperlinked convention card" this is too, too much for analysis during a game where you play two hands against opponents and then move one. If I was playing a 16 board team of four event, however, it would not be a bad idea.

 

Ben

[hrothgar]

It's Richard, actually.

 

Thanks for taking the time to make a detailed commentary.  Like many people, you addressed many of your comments about my "vision&" that major tournaments will be conducted using networks of laptop computers.  Potentially, it's worth spending a bit more time describing how I expect to take place.

 

While I think that this type of change is inevitable, I don't believe that the transition will be sudden.  Instead, a phased approach is required.  From my perspective, the rollout needs to occur in three stages.

 

Stage 1 is a trial deployment designed to validate that the system is stable enough for use in major tournament events such as the Vanderbilt, the Spingold, or the Bermuda Bowl.  The trial deployment needs to occur at two levels.  The first is the widespread deployment of the GUI which can be tested in Internet play.  The second is testing the server side system for use in team matches during sectionals and regionals.

 

Stage 2 formally rolls out the electronic playing environment for use in top level events.  The primary motivation for introducing this change is related to the potential to broadcast events and the desire to preserve complete hand records for all pairs.

 

Stage 3 diffuses this technology into more mainstream events.  In this case, the primary motivating force is the desire to increase the appeal of events by providing value added services.  

 

During Stage 3, the goal is to start by running a small number of events in which people bring their own laptops.  It is essential that participants in these events perceive much higher value added than the standard physical games.  Elements contributing to this value added in include:

 

     Complete hand records

     Detailed analysis of hands

     No requirements to manually duplicate hands

     Cross scoring

     ...

 

Ideally, this value added will prove sufficient to encourage individuals to invest in appropriate hardware.  Potentially, the ACBL might want to consider providing one sections worth of hardware to allow players to experiment with this format.

[pbleighton]

Richard -

I read your document with great interest. As someone who has been playing for less than a year, and who played his first club game yesterday, I won't presume to comment on the ACBL, tournaments, etc., except to say that my visit to the club gave me a dramatic illustration of the demographic challenges facing the ACBL - the median age appeared to be over 65, and at 48 I was one of the 3 youngest players, out of 40.

 

I do have some thoughts about the implementation of your proposed GUI standardization process (which IMO is a great idea, and is the critical component of your proposal), from my years as a manager/executive in the insurance industry (which has an ACBL-like attitude towards change), and as a systems consultant (my second career).

 

My experience as a user and programmer/systems analyst has borne out the cliche that the gathering of functional specifications (the "human element") is by far the biggest danger point in any system development.  From the ACBL's perspective, this is primarily a functional specifications project (the websites will do the actual implementation), though a necessary component of it will be prototypes, to enable the decision-makers to make final decisions.

 

Once the ACBL has been persuaded of the need to do this (a major undertaking in itself), I suggest the following process:

1) A committee be set up to implement the development of GUI standards.  This committee won't be a working committee, so it can be large (10-20 people).  It should be large enough, with enough "important bridge people", so that its decision will carry enough force to be THE DECISION OF THE ACBL, rather than a recommendation.

2) A working subcommittee of 3-5 people will be assigned to develop recomendations for standardization. Some/most/all of these people should have a high degree of computer literacy.

3) The subcommittee itself will never have the time (and probably not the expertise) to get the job done. It will hire a systems consultant.  The consultant will be an experienced bridge player, with significant online and face-to-face tournament experience.  The best candidate will be someone who has his/her own small-to-medium systems development consulting firm, or who is a senior consultant in such a firm.  Substantial systems analysis experience is crucial - many excellent programmers would fail in this task - this is primarily a COMMUNICATIONS job.  The committee should avoid the temptation to "brand-name" its work product by hiring a huge consulting firm such as Accenture or EDS, since such a firm will charge ripoff rates, and will delegate most of the work to 25 year olds (guess what size firm I work for  :)).

4) The consultant will have a budget sufficient to:

a) Research the alternatives thoroughly.  Use the existing

:) Develop generations of multiple prototypes.

c) Travel expenses to get in-depth feedback from subcommittee up front, and in several iterations of prototype generation.  Input would also be sought from the online websites.

5) Step 4) should enable the subcommittee to present 3 or 4 alternatives to the full committee, along with a recommendation for which alternative to use, and an analysis of the differences between the alternatives.  I believe that it is important that the full committee be made to feel that they are in fact the decision-makers, even though it is highly likely that they will merely ratify the subcommittee's recommendation, with a tweak or two.

 

The consultant will probably need 12-18 months from start to Step 5, and may well need to extend that, if the full committee wants to see a new prototype before making its final decision.  The requirements gathering/systems analysis won't be full time every day for the consultant, but there will be substantial additional costs for prototype development and redevelopment costs. Assuming a daily rate of $800-$1,000 (reasonable for a project this size, if you avoid large firms), I would estimate that the total cost for this project will be on the order of $400,000-$500,000.  As with all systems development estimates, this is probably low.

 

I think this approach will minimize the risk of failure of the GUI standardization project.  If something like this approach isn't used (if a committee tries to do the job itself, or if it uses a consultant without extensive tournament experience), I think the chances of failure are high.

 

Consultation with online bridge websites is crucial, by the committee/subcommittee as well as the consultant, as is the degree of standardization the ACBL will require. I think most or all websites won't be willing/able to support 2 GUIs - one for tournaments, and one for regular play.  Therefore the implementation of standards will de facto force all online sites which wish to have ACBL-sponsored tournaments (which I think long run will be most or all sites) to have very similar GUIs.  How similar (the level of detail of the specs) is perhaps more important than the actual specs chosen. I have only played at BBO and Zone, and they are quite different, even though I understand they were both designed by Fred.  This process will force some or all of existing online sites to invest a lot of time and money to comply with the specs, as well as grumpy responses from many (perhaps a majority) of their users, who will have to adapt to changes for the sake of being able to play in tournaments they have no interest in.

 

With all of the caveats above, I think that GUI standardization is a great idea.

[hrothgar2]

Hi Peter

 

Thanks for your thoughful response.   In particular, your insights regarding expected development cost were very interesting.  However, I must admit that your cost estimates are quite a bit higher than mine.

 

Potentially, this arises from differences in development models.  Professionally, I spent most of my career working in product development for software products.  [primarily TCP/IP stacks and embedded operating systems]

 

I agree with many of your comments regarding the cost required to support  complex development projects.  However, I have also seen a wide number of examples where so-called rapid protyping models have been able to produce products of equivalent quality for much less money.  We're I the ACBL, my primary goal would be focused on laying the groundwork for an Open Source development effort.  

 

I will note in passing that most industry standards were not developed a priori, but rather are an ex post recognition that a specification has established a position of market dominance.

 

In an equilvalent fashion, potentially the best way to foster the development of a standard would be to establish a close working relationship with a single provider, convince that company to agree to provide an stable interface specification, and move on from there.

[pbleighton]

Richard -

I agree with you on cost variability depending on the approach. I have been personally involved with:

a) As a primary user - a "back-end system" for an insurance company, whose original quote (1984 dollars) was $400,000/1year for initial deployment (on a Wang mini), plus $300,000 per year for support and enhancements. Actual experieince - $3,000,00/2.5 years for deployment, and about $1,000,000 per year for support and enhancements.  We were a startup and had no clue as to what we were doing, but still....

:) As a line programmer, customization of a $50,000 accounting package (Windows/VB/RDB) to give highly customized inventory and order processing capacity. Initial estimate - $400,000. Ultimate cost (including a vendor-mandated back end switch  >:)) - $2,500,000.

c) As a systems analyst/programmer/chief cook and bottlewasher - Half a dozen custom databases (mostly with an Access front end), where total cost came in at the quoted $20,000 - $45,000.

 

a) and B) have given me a perhaps too jaundiced view of major project cost.

 

I understand that in a software company environment, a few highly knowledeable decision makers can dramatically speed up the design process.

 

I have of course heard of the Open Source approach, but have no direct experience of it.  The problem with it in the part of the process that I was talking about is that I anticipated a "consensus" approach being developed - thus the need for a strong central figure, iterations of multiple prototypes, etc.

 

If a) the current (OKBridge?) model was deemed acceptable (perhaps with a few tweaks), and the vendor was willing to provide the specs, then I would agree with you that the cost could be dramatically less.

[JRG]

Very interesting!

 

You touched on several issues that I suspect may slow, or even prevent, the ACBL's adoption of the Internet as a means of conducting bridge games. I think there are also some additional factors.

 

- Without actual monitoring of players, it is virtually impossible to prevent cheating (e.g. use a cellular telephone to talk to partner, have a friend kibitz your table and talk to you via telephone, chat, etc.).

 

- Creators of existing online sites have a vested interest in maintaining their current model. They will only become vendors of commodity servers if made to do so by external forces. I'm sure the OK Bridge owners like the income they make.

 

- We shouldn't underestimate the value of socializing face-to-face. I personally play once or twice a week live, rather than online, because I enjoy meeting the people (but to be fair, the size (3 & 1/2 tables the last time I played - virtually ensuring a random result) and quality of the game may drive me away).

 

- The ACBL is not the only bridge organization in the world. I suspect that other bridge organizations would resist, quite strenously, an attempt by the ACBL to "take over the world".

 

On the other hand, I think your proposal solves the horrible problem of top level events (team trials, Bermuda Bowl, etc.). The mucking with screens, trays, hesitations, alerts, etc., could more or less be solved.

[JRG]

Boy, a lot of posts to this thread while I was writing mine!!

 

I notice that many of the posters have been involved in one way or another with software development (that includes me - I worked for research and development companies, also for "systems integrators", and as an independent consultant).

 

The one thing that most organizations try to do, and should do, is not to fall for the "Not Invented Here Syndrome". You don't develop a system like this from scratch - the risks are too high and the timeframe too large. You go out and throw some obscene amount of money at a Fred Gittelman and buy his system as a starting point.

[pbleighton]

"The one thing that most organizations try to do, and should do, is not to fall for the "Not Invented Here Syndrome". You don't develop a system like this from scratch - the risks are too high and the timeframe too large. You go out and throw some obscene amount of money at a Fred Gittelman and buy his system as a starting point."

 

That is absolutely right - in theory. I made the assumption in my initial post that (from the little I knew about the ACBL) they would never go for something so relatively easy. All interested parties would have a say, in order to get their buy-in, and the result would be something that would probably be no better or worse than what they could get from an outside vendor, at considerable more time and expense. However, if this process were followed, it would have a better chance of being accepted by the U.S. bridge community, included but not limited to the ACBL. I am sure that you and Richard have seen instances of companies which bought expensive software packages, only to see them languish on the shelf exactly because of the "not invented here" syndrome.

 

But I run on. Pardon my cynicism, but the whole issue of institutional resistance to change is (obviously) a hot button for me. :)

[stev_hav]

IMO, something along the following lines might be a good way to "get started" with use of computers for FTF play. It assumes the use of already-implemented software; no new development would be required.

 

Supporting software could be either a "public" network (Bridgebase, OKBridge, etc), or a "small group" arrangement (Bridge Baron, etc). Former would probably be "preferable", IF security could be adequately addressed.

 

What follows more-or-less assumes one "non local" player; would also be feasible (and perhaps best in earliest stages) with all four players physically at site. Practical benefit, of allowing off-site player, is that at least some such would be willing to pay a surcharge covering additional expense.

 

Intent of this is to permit one member, of a Swiss or KO team, to be physically remote from the site of a "live" tournament. At least in my opinion, this can be accomplished with minimal impact upon the interests of other contestants, and with very little exposure to any form of cheating.

 

In the interest of brevity, some specifics related to the online software will be omitted.

 

The "online" team will be responsible for provision of the following setup; some of which will require pre-arrangement with the site:

A. 3 Laptop computers, each with an Internet connection suitable for online play. Physical setup such that three onsite players can see each other's faces and converse normally; low-profile barriers to keep each player's screen, keyboard, and mouse pad concealed. Preferably, also the ability to make or receive phone calls to the offsite player.

B. Pre-duplication of all boards required for play; entry of such boards into one of the onsite computers.

C. Having a fifth member of the team physically onsite; to be able to "take over" for absent player should it become impossible to continue online play.

 

At time of entry, every other team will be asked whether it has one pair which is "willing and able" to play one match online. A "no" reply may be made, at this time, without specifying any reason. The Director will attempt to match only "willing" teams against the online team; if integrity of contest requires matching of an "unwilling" team, both tables of match will be played onsite in normal manner. (Fifth member participating).

 

To begin play of each match, Director will make the board images available to the computer. Fifth member of team--or perhaps a knowledgeable caddy--will be available to assist opponents with computer usage; both before, and during, play of any board. "In principle", offsite player has the right to have opponents' convention card faxed; this may not, in practice, be necessary.

 

Specific form of "alert" procedure will be at opponents' option. If both are familiar with "self alerts" (customary online procedure), these should be used; probably best that anything which would need to be alerted/announced at the table be self-alerted.

 

If opponents prefer, standard verbal alert procedure will be used, with minor changes:

A. Onsite player will give all required alerts and announcements for his side's calls.

B. Opponents "should" give an indication, at time of making an alertable call, that an alert is involved. If this is not done, altho a verbal alert is given, onsite player may require corrective action.

 

In event of mid-hand connection failure at tournament site, fifth player or caddy will be immediately available to help re-establish; in event of offsite player connection failure, some two minutes will be allowed for corrective action. If problem cannot be resolved, Director will determine whether to cancel the board or assign an adjusted score. Tending to cancel the board, unless play has progressed to the point where final outcome is reasonably clear. Should be "presumed" that it's not feasible to continue play of interrupted deal using cards; exceptions--when failure occurs during auction--are conceivable.

 

At least initially, Swiss Team would appear to be most practical. Pair events would tend to involve too many separate individuals; unless a pretty-high percentage of the "willing" pairs were also familiar with the procedures, it would be difficult to finish rounds in timely manner. Knockout would afford Director somewhat less flexibility in matchmaking. Under some circumstances, it might be necessary that BOTH opposing pairs be "willing". Might be viable, however, in bracketed events; if Director were allowed some leeway to deviate, from strict use of masterpoint totals.

 

Offsite player would be "expected to":

A. Be one specific and identified person; changed only when it would be permitted to do so in normal play. (Between swiss matches, or after comparison in KO).

B. Refrain from any consultation. IMO, however, possession and reference to own convention card ought to be permitted; enforcement of rule against this is difficult enough at table . .

C. Ideally, have a phone connection which is usable while online; ability to receive faxes might also be "desirable". Use of any form of "instant messaging" would be prohibited while cards remained concealed, and probably "should be avoided" even between deals.

 

Case of KO opponents also wishing to use an offsite player, assuming software compatability, should be simple enough. Should probably, however, permit only ONE member of each team to be offsite, except perhaps by mutual consent.

 

Fact of expected offsite-player participation should "tend to" be disclosed in pre-tournament publicity; with mention of a url at which details can be viewed. This might well help attendance; something new and novel.