Join Bridge Winners
All comments by Larry Lang
You are ignoring the author of this comment. Click to temporarily show the comment.
Ah what the heck. I might as well open myself up to some hate mail.

Technology does not help Bridge. It is destroying it.

If kids didn't have computer games and cell phones, they would find something else to do with their time, like play cards.

Bridge is driven by the innate need to socialize. Technology discourages socialization and thus discourages bridge. At my club, instead of hanging around to visit and discuss hands after the game, I hear – “Ah what the heck. I'll get the results in 15 minutes. I'm going home.”

We hear about Demographics, but what is driving those demographic behaviors? Technology.

If I'm a reasonably smart guy, I can exercise my brain by programming and get $100 per hour. Or I can do the same thing by playing a silly card game called bridge. Which would you choose if you were younger and needed the money?


Just to open myself up to more hate mail. I really think the ACBLScore+ debacle was caused by technologists that couldn't think past their keyboard and the web. They never really considered what they were trying to do – they just wanted better technology.

What a terrible curmudgeon I am. I better swallow some Prozac.
June 27, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
I think where you live matters. For example, I'm from an area where everyone is 15 minutes or less from where we play bridge.

We thought that morning games would soon overtake evening games in popularity. But for die-hard players it's the reverse. They prefer the night games. During the day, they “do stuff”. At night, they come to battle at the Bridge table.

We have free convenient parking, and no fear of crime where we play (or anywhere for that matter).

I run a day session, and we initially brought in 7 tables of new bridge players, which is quite a few for this area. But guess what? They aren't any younger than the “competitive A-holes” that play at night.

If anything the new bridge players are dying off faster. Competitive bridge players are too obsessive and too stubborn to die, and seem to live forever.

Night versus Day? It's just a symptom. Younger people don't play Bridge, girls don't join Rainbow Girls, guys don't join the Elks. They don't play cards very much. They sit and text each other on their phones.

I suspect if you polled the age of people who play online. It's not much different than at clubs – unless they're from the Scandinavian countries.

Bridge is rapidly becoming irrelevant in the US.


June 27, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
I strongly disagree that playing Bridge while being tied to a computer at home is progress.

Studies have shown that Bridge does improve the quality of life for older people, and after a certain age, even more so than physical activity.

But they've broken down the cause of those benefits into two categories. 1) Face to face contact with another human being, and 2) mental stimulation. Both are beneficial, but the brain is most active, lit up, and engaged when one or more people are in the same room. Social contact is more important.

June 22, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
My attempt to recoup some of the existing ACBLScore code gave mixed results. The plan was to load the source text into an Integrated Development Environment called Lazarus, and turn it into easily maintainable software so we could replace the code at a leisurely pace – not all at once. This would allow us to add new features to ACBLScore, establish inter process communication so that software apps could flourish on a symbiotic basis, and get us a Mac version as well – pretty quickly.

Lazarus is a great IDE and a wonderful tool. But I quickly found out that ACBLScore uses old libraries, and I don’t have them. Also, the ACBL purchased custom GUI components that I don’t have. The old components are out of date, nonstandard, and difficult to use. It’s like trying to convert software that is 90% complete. Ten percent of 200,000 lines of code is still a lot of work. I’m sure ACBL could cough up all this stuff, but I don’t think they’re interested.

Even if I did manage to find replacement libraries, and swap out GUI components, the ACBL could render the code obsolete without even breathing hard. In fact, they already have inadvertently. The source code I have is 2011 vintage. So I could spend a lot of time, do some great work, and have it torched instantly. No thank-you.

The third issue is my own human nature. I found it very painful to look at line after line of fossilized code, without deleting half of it, and refactoring the other 50%. I’m not saying that Jim Lopushinsky did a bad job. But because of the ravages of time, almost every line should eventually be replaced. It’s not personally satisfying to constantly cover your eyes and bite your lip. It feels like taking out the garbage. Besides, the ACBL must be a part of the decision making, and they’re busy with other things.

I give up. Without the full support of ACBL, it’s not worth it.

Does “Time equal money”? The advantage of putting a wrapper around the existing code is that upgrades will come sooner. I guess that’s a question for others to decide.
May 12, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Hi Tom,
Great idea. Here is what we can do.

I previously dinked around seeing how much effort it would take to duplicate ACBLScore with Access and then I played around with VB.NET. The screens and data base structure were easy to set up, particularly with VB.NET, but understanding all the hundreds of rules that the ACBL has for games and master points, and implementing them was going to be a horrific task.

So I am beginning my third experiment. I'm going to attempt to create a new/old version of ACBLScore by loading it into the Lazarus IDE and debugger and then replace any custom components that are outdated. If all goes well, within 2 weeks we could have our own copy of ACBLScore. I'll call it Bridge Wizard. I'll get back to you and let you know how it's going – every week or so.

I cannot release the source code to anyone. I think that would really piss the ACBL off. But if I behave myself, hopefully we can fly under the radar, and hopefully we and the ACBL can live in peace, work with each other, and leave our lawyers at home.

In the mean time, pick which feature you would like to add first. You can download a technical manual for talking to the Bridge Mates via software off the Internet. Bridge Mates are operated through an Access data file that controls the devices. View the new version of Bridge Wizard as a black box that you can send commands/information to and get answers back. We can 1) put all the functionality within Bridge Wizard, or 2) we can have it call an external program that you or I or we can write, or 3) visa versa. So begin to think how you might want this to work. We can get together and define interfaces if my experiment proves a success.

It would be nice to eventually set up a “Common” area (collaboration site) where we can release prototypes, create specs, get comments, and so on to all interested bridge players. If you have any ideas, let me know. That's not my strong point. Eventually, the more people we get involved the better.

As for the rest of you out there, if anyone has a list of recent changes made to ACBLScore over the last 4 years, it would be nice to have.



May 7, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Nicolas,
All true.

Still, ACBLScore provides more to go on than anything I'll get from the ACBL. Wasn't that part of your experience?

Just as an experiment, I took an Access Database, set up a file structure, and dashed up a few screens. I found that I had no idea what the “rules” are. They just aren't easy to find. And I don't think the ACBL is willing to give them out.

All of your other statements are true as well, and you make good points.

All I can say is, there is some similarity between fixing Jim's code and rewriting code for parallel computing. One of the best pieces of advice I got was, “Copy and paste are your best friend”.

I think that's true here. It's easy to underestimate how quickly you can get from point A to point B if you're willing to drudge through the work.
May 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Greg,
I meant “compiler” as a tool that targets specific hardware platforms (with the nuance that it spits out machine or intermediate assembler code versus an interpreter that doesn't). If that's not a reasonable approximation of how the word is used, things have changed.

Different languages tend to favor different User Interface tools. In my mind, languages are not necessarily separate from certain tool sets, although they can be.

Lazarus, which was written in Object Oriented Pascal (definitely a compiled language) can be used for different languages, but it favors Object Oriented Pascal. When you start a project, Lazarus asks which types of platforms you want to support, and the language you want to use, and for your compiler options, and sometimes it writes some code (which is eventually compiled) selecting the libraries that will be used.

One of the nice things about Object Oriented Pascal is that the libraries are placed inside the compiled code, mitigating the old concept of DLL Hell. One exe file could be used stand alone to run an entire application. So, yes, the user interface tool is language specific, platform specific, and a part of the compiled code – in at least some senses.

Even though both Free Pascal and the Delphi tools favor Object Oriented Pascal, and although commonality is desired, the two have different IDE tools.

I didn't say I was going to write code using search and replace. I said, search and replace could be used to cut out the code that wouldn't be used. I was mostly thinking of the {Ifdef Win32} kind of brackets which separate Win32 from DOS.

I said that a “small sliver” of code might be saved, and might be useful. That's considerably different than how you read it.

Who is putting words into other people's mouth?

I've been through the same experience you have, trying to read the ACBLScore code, and I had the same reaction.

But I didn't have a debugger available, and I'm guessing that you didn't either, although I don't know that.

Usually, when I encounter another persons code, if I can, I slap it into a debugger. In a typical line of ACBLScore, the routine of interest calls a function called XYZ. You look at the code and say, “what the heck does xyz do?” It isn't even remotely clear. “Well, I'll go check it out.” But where the heck is it? In which of 50 globally linked files is it hiding? You can spend half an hour or more just tracking down one routine. But if you have a debugger, you just hit the next key, and it takes you XYZ, shows you what got passed, and lets you step through the code to see what it does. Then, when you're tired of that, you set your next break point, and see what the next piece of code does.

One thing I didn't like about the RFP process was they shipped us this cryptic code with no way to understand it. No tools and no documentation. How were people supposed to bid on something so unintelligible?

I tried using Windows as a massive text search engine to find the different XYZ functions within the 100 to 200 files or so, but the Windows multiple file search engine has a bug and doesn't work well.

Barring the debugger, I would take the code to a friend at Battelle. He has written a Perl Script specifically to handle this kind of situation. The script combines files and then prints out routines in the order they might be called, duplicating the program call stack. He calls this “flattening out the code”. The script also put markers and comments all through the gigantic file, noting where you are in the code and how you got there. Definitely a text editor with a search function would be helpful here as well.

When I used Delphi, it had a tool available that basically did the same thing. It drew out the routines and showed how they linked together. That would have been a nice diagram to see, but they didn't ship that to us during the RFP process. I don't know if you had one of those diagrams when you did your work.

I said I would slice out DOS, GUI, and database stuff. That takes away most of the code that is event driven and leaves code that is more like an algorithm. I'm thinking the remaining code would be much easier to understand.

The other thing I noticed is that the code was written in an in-line fashion with 100 different exceptions coming from different directions. “IF this is a Swiss team game, do this, if it's Saturday, then do that, if it's a club game, stand on your head, if this one of two sections, go pee in your pants.” Ugh!

I once had to rewrite a program like that, written in Assembler. I used a lot of cut and paste to break the code into parallel paths – more like Object Oriented code. This worked well to make the code readable, but given more time, I would have used a more robust Object Oriented approach.

Many of Jim's labels were one or two letters short of being understandable. If he had added just a couple of more letters you could tell what the variable stood for, and what he was trying to do. Actually, search and replace can be good for this kind of problem as well, if you're just interested in improving readability.

Also, I said “small sliver of code”. So the task is not as Herculean as yours was.

I didn't say I could rewrite the code all by myself. My proposal has always been to put a wrapper around the code, and then replace it piece by piece, until the code inside the wrapper has mostly disappeared.

Nor did I mean to imply the decision on the Internet was already made. I think the decision has not been made, and the committee will eventually decide not to require an Internet connection. But I want to make damn sure that's what happens.

I never meant to imply that you don't know what you're talking about. But I've been around the block quite a few times myself. My last big programming job at Battelle was to write a simulator for the 386 processor as part of cyber security research. You can't appreciate how big a task that was unless you download the 3 different technical manuals (about 100 pages a piece) explaining the thousands of instructions.

By writing my unit tests up front, I managed to deliver code that was error free.

Here is a scenario. Suppose we agree that the GUI for ACBLScore is sick, but not yet terminally ill. We can live with it for another couple years until it gets replaced. Perhaps we replace a couple of screens at a time. Suppose we agree that the same is true for the database, and the code itself.

If we were going to maintain it, the first thing we would do is find a debugger. How about the Free Pascal debugger? It can accept both Turbo Pascal and Delphi code. It has a tool that converts Delphi code to “generic” Object Oriented Pascal, whatever that means.

We still need something for the GUI. How about Lazarus? It also supports Delphi UI components, and can convert them into generic UI components. It can convert Delphi project files and all turbo Pascal code, and turn it into an application (or a “package”).

It is possible, we could take the ACBLScore code, load it into Lazarus, and convert it in 2 hours. But I've tried this already and there is one problem in particular. Jim bought and used some components that Lazarus doesn't understand. They would have to be replaced by more generic components, and some of the interface code might have to be rewritten a tad.

Let's say we do that. Let's say we find 20 components that Lazarus is not familiar with. Maybe we can replace them in 20 days, one day per component. Our new components will all be free, and more useful, and they'll look better.

What next? Well, we can compile the code for a Mac. They claim it works. Why not try it? It could be that in 30 days we'll have a Mac version as well.

So I guess I can convert the code into Mac code in 30 days, or at least there is some chance I can.

There are other things that can be done as well:
1. Cut out code that just supports DOS
2. Replace all the screens, probably a couple at a time.
3. Change out the database and convert it into a generic SQL version instead (I prefer access database, but whatever).
4. Provide all the web enabled features described earlier.
5. Eventually replace all of the code with self documenting code.
6. Provide tool tips
7. Automatically store game reports on web
8. Support default rules for clubs (type of movement, number of boards, default director, time slots allowed, etc. )

You get the idea. The items on the list can be started within a couple of weeks?

Not so hard.
May 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Greg,
You weren't sure what I meant by compiler switches.

I'm not being argumentative here. You're obviously heading down the road, and have already made some decisions. And I understand you're not the guy who wants to require a live Internet Connection. But someone does.

The whole idea of design by committee scares me. In the projects I've seen, no one sees the entire picture, so the committee member with the loudest voice usually carries the day. And he politically implements his views by agreeing to extra features requested by others that are of questionable practicality. The final application tends to look like an elephant with wings that lays eggs.

I'm hoping you and the Tech Committee will take the time to fully understand the “other point of view”. This is nigh impossible because we all have our own set of collective experiences. Consequently, what some people feel is “obvious” is insanity to others.

For example, I cannot imagine why anyone would want to put the current functionality of ACBLScore on an Android. But apparently other people disagree. Am I insane or are they insane? Don't know. I haven't seen what they've seen.

Back to the main point. In FPC (Free Object Oriented Pascal) the developer gives the project a list of the different platforms that will eventually be targeted – Linux, Mac, Windows 32, Windows 64, etc. The compiler picks the libraries for the generic GUI components (QT, Widgets, etc.) based on the list of supported platforms.

Later, when it is time to build, the programmer recompiles once for each different platform. For example, once for Windows 32, once for Mac, once for Android, and so on.

This is not perfect, because the look and feel of a Mac app is different than a Windows app. This is especially true for a mobile app. If you want the compiler to adjust the GUI sizing, look, and feel, based on the target device, you've got to pay the big bucks and move up to Delphi.

Or you can go to the .NET world and use their new display technology (the GUI code looks a lot like XML) and use it to define the GUI functionality in a generic way. Typically a display designer will customize the look and feel for each platform later.

These features were not available the first time around when Nic started with ACBLScore. Delphi was near death, and the Free Pascal and Lazarus project were not mature. But they are now.

This all falls back to my original premise. Web based and native code tools are in a race, and they are both (I presume) moving targets. Currently native and hybrid code (which have always provided the majority of applications on mobile devices) are making a resurgence in popularity. Native apps are winning the war, if one wants to argue that such a war exists, but this could change again.

Once again, we all have biases, and not everyone agrees.

Let's say that we make the following assumptions. The old ACBLScore GUI needs to be completely replaced. The database needs to be completely replaced. All the DOS/Assembler code needs to be cut out. (I think those are safe assumptions). It's actually easy to do with a text editor that has find and replace.

Is the remaining code worth anything? The experts say no, but I really suspect they don't know, because they couldn't take enough time to find out. In order to see if the code is any good, all of the above has to be removed first. There are tools that will tell you how the remaining code is structured. Then someone has to go in an restructure the code so that it is readable. And then add comments as needed.

You're right, the global variables make the program almost impossible to deal with in the present form. But that can be taken care of.

I'm sure you've seen bad code in almost every possible language imaginable. It's actually pretty easy to write cryptic code. That doesn't mean that with a little spit and polish the remaining sliver of ACBLScore code is worthless.

When I consider what would I would need to rewrite ACBLScore, the toughest thing is identifying all the rules! Red points, platinum points, Special enhanced Membership games, sanctions – Handicap and Strat rules. And then the program has to identify all the exceptions and tell people what they can't do. What a rats nest.

In my view, if nothing else, the remaining code could eventually be used to provide a baseline understanding of what the rules are.

Anyway, back to your original remark. Most of the major compilers are moving towards generic GUI and cross platform compilation. Object Oriented Pascal is already there. .NET is rapidly moving that direction, but I don't think they've completely closed the loop yet. Of course Java supposedly has always had that – if you like Java. Python is sort of there. Ruby is definitely there and it doesn't have to be restricted to a web connection.


May 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Greg,
I have problems seeing the web-based advantages, because the purported advantages can all be obtained by having the application check a web based server for updates when it powers up.

Mac and mobile devices can be handled by compiler switches.

If the Internet connection is active and exists, the application could check for anything new and update itself accordingly. This could even include downloading a new version of the program. And, if the Internet connection is active, the application can use any of the other advantages associated with the web.

If the Internet connection is down, the program could run stand alone until a connection is presented to the application. A redundant system.

To me, this is the “best of both worlds” for the user. It might not be the best for the programming team. But this is not a weird approach. In fact it's quite common.

Although it's not important, as I've mentioned before, if our club has a power failure during the day, we can still continue the game with ACBLScore and Bridge Mates. We have portable computers and Bridge Mates with batteries, and the portable computers power the Bridge Mate server through the USB port. We can even have a computer blow up. We have a spare portable that is shared by all the clubs and kept in a closet.

The only thing that can knock our club for a loop is a version of ACBLScore that requires an active connection all the time. And that would surely bring us to our knees.

My first most important feature is – able to operate stand alone without an Internet connection.

My second most important feature is – stronger integration between the Bridge Mates and ACBLScore. As an aside, if the web based application wants access to the computer's USB port, you need to add additional software support. I forget the name of the software, but I'm sure you're aware of it. This is another complication caused by a decision to base the entire application on web based technology.

Here is a previous quote.
ME: “Sure, I can ask that this feature be included, but will the ACBL accommodate me?”
YOU: “YES.”

Okay. I'm asking that the next generation of ACBLScore be able to operate without a network connection, just like the current version.
May 6, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
I was taught, first you define what the user wants (and doesn't want) and then you match it to the proper technology as the second step.

Web based apps are great if you want to expose your application to as many people as possible. Even if your method of downloading a native app is very easy, people don't like clicking yes, after they have been warned that the downloaded application could take over their computer, steal their identity, and end the world as they know it. So if you want to encourage lots of people to use your application, web has a great advantage.

However, if the application must go off line occasionally, then you have to download a local server, so you're right back where you started, and the web app loses it's advantage. In fact it probably has more problems than the native app.

ACBLScore has a captive audience. Either you need it or you don't. There is no need to entice people to use it.

If using an app is inconceivable without web access, a web based approach makes sense. But if there will be users with legitimate reasons to run off line, requiring an Internet connection makes no sense to me. For example, the use of Bridge Winners, the ACBL Web Site, and Bridge Base On Line without web access is inconceivable. If the Internet goes down, you wait until it comes back up. If you don't have web access, you don't use those applications. This is not brain surgery.

But many local clubs don't have reliable Internet access. And if you are in the middle of a game and the web goes down and knocks out ACBLScore, this is a very big deal.

The web is fast enough for most tasks. However, I'm concerned about rapid data entry at the end of a bridge session using travelers. My web connection speeds up and slows down. Yes, the programmers can probably take lots of extra steps in the code to make the speed acceptable, but why make the extra effort, when it would probably be much easier to guarantee fast data entry with native code. It doesn't all have to be native code, and I could be all wet, but it is a concern of mine.

Greg is suggesting a central data base is best. And, perhaps he's right. But personally, I like my little game files that I can move, copy, and delete whenever I want. I like it that I can open the Bridge Mate files using Access. I use the Bridge Mate files and the ACBL generated HTML results to create a recap sheet that shows final contracts with the scores.

If the database is completely centralized, I lose control of my own processes. For example, I often use ACBLScore to create new bridge movements and store them for re-use. When I do, I am essentially keeping my own home grown database. If this capability is moved to Horn Lakes, I will probably lose this capability. Sure, I can ask that this feature be included, but will the ACBL accommodate me? Right now there is talk that the ACBL doesn't even care if I can run the ACBLScore at my current location. If that's true, why would the ACBL support the other things I like to do?

In truth, even with a web based approach, the data is captured locally, and then posted. Data synchronization still becomes an issue.

I view the ACBLScore process as a data concentrater. We start out with the Bridgemate logfile with each board, each contract, each result, each round and on it goes, and the ACBL game file, which I find handy. Sometimes I need this data when a round gets screwed up, or when ACBLScore and BridgeMate have a hiccup. But it doesn't take long before all of this data becomes of little value. Maybe a couple of weeks after results have been posted, and after all corrections made, the value of these files dissipates and it's hard to imagine that the ACBL (or I) would have any need to store them long term.

The final game results also eventually get concentrated as well, into final scores, overall places, names and ACBL numbers, game information and so on. The games gets further concentrated into monthly reports (admittedly, daily updates might be better) and credit card information. If I understand Nic correctly, sending in an encrypted EMail file with credit information is more secure than handling everything over an over reaching master web based approach. Any way, as the data gets old, the club manager gets to decide when to delete it, and the size of the data pipe shrinks as it heads up the ACBL. This also suggests local database capabilities might be appropriate.

I developed a program for my Unit that counts the number of different players that each ACBL member partners with during the year. Will this information be available? If the database is centralized, personal access to the data becomes less likely.

The ACBL is not the most open organization – about anything. If they can keep data secret, they probably will. But more likely, someone will say, “I would like access to this data, we used to get it before.” And most likely the response will be, “we're working on it. Can't do everything you know.”

Does ACBL like people to poke around in the Game Files? Hell no. Is there any reason for this? I can't think of any.

I was told by a Technology Committee member, in concurrence with the first RFP – if the software development tool is not free, it probably isn't any good. Really! That's sounds a little judgmental. Bridge Mates are Access based, and the Bridge Mate company is not out to lose money and make stupid decisions. Their software is impressive, in my mind. To make such a blanket policy seems bureaucratic.

Greg and Nic are not the only people who really like Ruby. And they have good reasons. But there are also Python fanatics, Windows .NET fanatics, Delphi (Object Oriented Pascal) fanatics, and even some Java fanatics. Usually, you look at the specific situation and then try to find a matching language.

I see that the next generation ACBLScore needs to be easy to maintain by a programmer with reasonable training. To me this suggests either Access, VB.NET, VB, Object Oriented Pascal, or Python. Ruby programmers love it, but they are still a minority.

I can see the concern that Object Oriented Pascal may be on life support. It keeps hanging in there, and currently support is growing, but I understand the concern. But to say it is not currently a practical solution is just ignorant. To say it cannot port to Mac, or 64 bit Windows, or whatever, is just plain incorrect.

There have been function point productivity studies, but they are far and few between. Of the older ones, SQL, VB, and Delphi do the best. Surprisingly VB is something like 50% more productive than C#. To say that these languages should be shit canned is also ignorant. They are very workable and efficient and they'll stay around for quite a while.

For Python, and Ruby it is too soon to tell how the popularity contest will fall out. But if past performance is any prediction of future outcomes, it will be another decade before any final verdicts are obvious. Currently Python is very strong, and runs on many platforms with different compile options. Ruby is in decline, but who knows?

Ruby on Rails is a very strong contender for an application that is strictly web based, but is it right to make Ruby a requirement at this point in the game? Nic was using many different languages – presumably he made the best choice for each task – as he saw it. That's how it should be.

To say ACBLScore cannot be maintained is also incorrect. I could. And I'm not a particularly good programmer. I'm not saying I would want to. Or that we should. I'm not defending Jim's policy of zero documentation. Eventually, all the code should be replaced. I'm not saying the code is readable without a debugger, or a Perl Script to flatten out the text. But it is workable and it can be replaced incrementally.

We can keep the patient alive long enough to upgrade code at a friendly pace, rather than betting all the money on one big, risky, horse.

Maybe the code should have been replaced sooner, but that wasn't on the ACBLs list of priorities. Most companies view any code that is written after the programs first release as maintenance. By this definition, many (most) companies devote around 80% of their software budget to maintenance. Most programs are “ongoing”. Just because the ACBL possibly messed up and lost out on most of their investment by not maintaining the code more aggressively is not a great reason to have them start a new project from scratch.

I'm hoping the ACBL will look at user issues first, and then perhaps divide and conquer the next version of ACBLScore. And match the technology to the requirements.

















May 5, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Adam,
I just got around to reading your note.

I probably have been smarting off too much. Clearly I have not communicated very clearly, at least to you. So let me try one more time. I feel like I'm repeating myself, but here goes.

I honestly believe that ACBLScore should already have been fully replaced – at a third of the price that has already been spent. I don't expect anyone to believe me or care what I believe, but that's what I believe.

Under normal good software practices, at least the ones I used for my projects:

The code would have been mostly self documenting and easily maintained.

Portions of the design document would propagate from the Unit Tests.

The technical document would mostly propagate from the design document.

The User Manual would be small and mostly propagate from the design specs and screen shots.

The Appendix of the User Manual would detail important business rules that members might be interested in, such as how master points are computed and so on.

Much of the information in the Appendix would drive the application. The business rules would come from either text files or the database. The business rules would be easy to change by a layman that doesn't know how to code (assuming he has been granted access to change them).

There wouldn't be any super star programmers. A monkey could do most of the work, as long as he knows to program?

The User interface would be functional, self explanatory (after the user pokes around for a couple of minutes) but not necessarily beautiful

Help files and training would not be needed.

So how is my approach any different from what Hammond is doing or what the Technical Committee is cooking up?

1. Every feature would be honestly evaluated up front for the cost and the benefit to the ACBL and stake holders, including Mac and DOS and iPhone capability. There would not be any – “Hey that's a great feature, let's add that one!” Features would be costed out and high payoff features would be added first.

2. The “Big Bang Theory” of software design would not be used. The design would be modular to the max. That is – Agile Programming. Improvements would be added piece by piece. Users would start seeing improvements within a couple of months. If self testing is added to the code at the same time you write it, you can get away with this approach.

3. Maintenance issues of the existing ACBLScore would be considered up front during the design of the next generation ACBLScore. Refactoring (replacing old modules with better new ones) would be routine. New code would be designed with the assumption that it would eventually be replaced.

The existing design of ACBLScore would be torn apart, analyzed, and components that could be reused would be identified. Code that is not executed or not needed by the new specs would be removed. This would decrease maintenance costs, immediately. It would also help establish existing business rules, design concerns, and flow into the requirements document of the next generation program.

4. Monthly milestones would be evaluated on a value earned basis. In other words, if the code don't run yet, that module is zero percent done. The project could be stopped at any time, and the ACBL would receive full value for what they paid for, up to the last monthly cycle.

5. An Analyst would talk to every single type of stakeholder, and interview them in detail and find out what they like about their “job” – what they don't like, improvements they would like to see, and what they wouldn't like to see. This would propagate into the Cost/Benefit Analysis and into the requirements document.

Subject matter experts would be cultivated and used during the entire development effort. Different experts and perhaps different programmers for different User Roles (club manager, club director, tournament director, Bridge Mate User, Head quarters computing) would contribute to the development effort.

6. The next generation ACBLScore would be “open architecture” and modular so that other interested parties could easily develop companion applications and plug in modules. This would open up competition among software developers, and the ACBL could cherry pick applications that they particularly liked.

7. As you can probably surmise, the requirements would come in over a period of time in a piece meal fashion, depending on the module being worked on next. The project would be shepherded by thoughtful analysis, and consensus, rather than committee.

7. Design and technology decisions would be driven by user requirements and cost, not the other way around.

8. Technology bigotry would not rule the design process. User needs would drive the development effort instead. They would be identified, prioritized, costed out, reviewed by the ACBL and stakeholders – and that would drive design decisions and timing.

9. Cost would drive the design as well. The cost of using less popular technologies would be carefully considered and factored into any cost estimates, but in the end, total cost would be the decision maker – so users would get the most bang for the buck.

10. The application would probably be hybrid. Features that are best handled by web based technology would be handled by web based technology. Features that are not – probably wouldn't be.

I didn't say I like using ACBLScore. If I gave you that impression, I apologize. But it is an amazing piece of work for when it was done.

After seeing many of the latest comments (and some of them leave me stunned) it sounds like the old ACBLScore will be more useful to me than what's coming next. But that doesn't mean we should stop the train. If you stand still, you're moving backwards.

On the contrary, I think ACBLScore should have been replaced 2 years ago.

If you can stop thinking that it's either all ACBLScore or no ACBLScore, we can have a “next generation” application in 6 months. Every thing you want is very doable in the next 2 years.

But I think Greg is right. It will be another 5 years before a better thing comes along.



















May 4, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
We use portable computers, and some of us play in the day. Most of us take our computers home with us, so when the Internet is out, we can transfer the file and send it over Internet, and we do our monthly reports separately.

Also, we have a program that adds the text from our bridgemates to the recap sheet so our sheets show score and contract. Some of the members want to add opening leads, but others are resisting.

We can play all day without power. We can't do that if required to be connected to Internet.



May 1, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Greg,
I issue the following challenge to you, since you are the only person on the committee who will give this community the time of day.

When the next generation of ACBLScore is released, what clear quantifiable benefits will it provide? How much is the Committee assuming these benefits will be worth to the ACBL (and stakeholders) in dollars? What development costs is the Technology Committee assuming will be needed to obtain those benefits? Technology benefits don't count. The only benefits that matter can either be traced to user capabilities or future maintenance costs.

If the committee ever does concretely identify the benefits they wish to obtain, and the associated costs, is there any possible way that outside interlopers could convince the committee that they can achieve those same benefits at half the cost?

Perhaps this will achieve the same results that Nic had when he tried to call out Whipple – the cone of silence. But there is no harm in trying.

May 1, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
I understand what you mean by web based. I was reacting to a question that indicated the committee is considering requiring an Internet connection all the time.

YEARS IN THE FUTURE? Bridge, as we know it only has about 5 to 10 years left. It bothers me that we are anticipating the next generation ACBLScore to last for 15 years or so. It will be irrelevant in about 10 years.

Impossible to take ACBLScore backwards? How about the present version of ACBLScore+. Regardless of whether the product is good or not, it has taken us back 3 years and $2M, according to the Tech Committee.

All I can do is warn you about where you are headed, and I can't do much more than that.

Another $800K. The first full release will be in August of 2016. A cool reception at best. And if you do a cost/benefit analysis, you will not have given any benefits to ACBL, except code that is “more maintainable” – which I cost out as worth $200K. The application will be regarded as “probably a mistake” – but we must keep going. Maybe we'll get it right the 3rd time around.

I hope I'm wrong. But I seem to have an uncanny knack for predicting these kinds of things.







April 30, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Greg,
I'm glad you're putting out the survey, but to me it indicates that the Tech Committee is willing to take ACBLScore backwards for no particular reason, other than there is a bias about the program being web based so it can run on a Mac.

If that's the case, I'd rather that you didn't do anything at all and left it alone.

I guess we just have very different views on this one. Sorry if I'm being rude. That's not my intent.

I'm going to make a prediction here. There will be a new ACBLScore, it will be web based. It will work on a Mac. The ACBL will spend a lot more money, and no one will like it any better than what we already have.

So please keep the old ACBLScore available for us cave dwellers.




April 30, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Kevin,
I'd debate with you, except I can't. That's because I agree.

I keep wondering, along the line of Jeff Lehman's comments, why would I be upset by a questionnaire? After all, taking the time to send one out indicates the committee is doing their job.

I'm bothered because if they have to ask such a silly question, they clearly have no clue as to the conditions that some clubs operate under. No doubt, I've got blinders on as well, and I'm only aware of the clubs I've seen.

There used to be a guy called the Analyst. He would go around and talk to all stakeholders, see how they do their job, and then compile a well thought out list of requirements. When he's done, a good Analyst should probably become President, because he understands how the company works better than anyone else.

No more it seems. Joe Hertz has indirectly mentioned this as well. So perhaps you've hit the nail on the head.
April 30, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
One last comment and then I guess I'm done.

In Richland Washington, we have 7 different club sessions, and 5 different clubs. They all meet in the Richland Community Center, and our Internet access comes off of Wi-Fi. It goes up and down, depending if help is around to reset their end of the connection. We pay $1 dollar a person for rent, so we don't complain – about anything.

Adam is not the only person who thinks that our clubs are living in the stone age. It's just too bad for us if we can't depend on Wi-Fi.

To most people, technology is more important than users or development costs. This doesn't surprise me at all. It is the way of the world. Who says history doesn't repeat itself? We are right back to where we started off the first time around when ACBLScore+ was conceived.

To be fair to Nic, his solution did allow ACBLScore to run standalone. But he was mostly contracted to produce the same old thing, but make it prettier and sexier. I'm way oversimplifying things Nic, I know it, so please don't be offended. You did what you were asked to do.

But from where I sit, it's Deja Vu all over again.





April 30, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Actually, 3 months ago, we held a bridge game in a place like Starbucks, and we didn't feel we were cave dwellers.
And my provider went down for 6 hours just 3 weeks ago. I have an automatic garage door opener on my cave.

Can you imagine running a big tournament at Day's Inn and all of a sudden, oops! The internet went out. Have you ever used the Internet at Day's Inn? It's a real treat.

But more importantly, there is no need for that kind of dependence.

If ACBLScore has to be ruined because of some costly architecture decision that shouldn't be there, then split it into modules. Have a stand alone module that let's directors do their jobs, and have a separate module that satisfies the programmers need for an Internet architecture.
April 30, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Adam,
The items you mention require intermittent Internet access, and they are desirable. But there is a big, huge difference between Internet capability and Internet architecture.

Windows is updated periodically, but it is not an online architecture. It is a native application. Apparently so are the majority of mobile device applications. Periodic updates, and downloads of membership database can easily be done for ACBLScore whenever Internet is available. These features are now provided from the cloud, and they aren't that difficult to add. And that would address everything you are talking about.

If we want the best of both worlds, fine. I can see that. But to tie directors to a live Internet connection is madness.
April 30, 2015
You are ignoring the author of this comment. Click to temporarily show the comment.
Bridge Winners, google docs, gmail, and BridgeBase Online all have very compelling reasons to work on line. The Internet provides user features that are mandatory for what they are trying to achieve.

ACBLScore does not. There are many reasons not to require online operation for ACBLScore. I can only see problems, and increased development costs. The latest studies show that native applications are now growing in popularity and that businesses that favor native applications are more profitable.

The following link, written by a developer at Mozilla is just one of many articles on the net that say the same thing.

readwrite.com/2015/02/27/native-vs-web-apps-ceasefire

Developers that only have a single hammer should stop trying to turn users into nails.


April 29, 2015
.

Bottom Home Top