Join Bridge Winners
All comments by Larry Lang
1 2 3 4 5 6 7 8 9 10 11 12 13 14
You are ignoring the author of this comment. Click to temporarily show the comment.
Jo Ann Sprung is right on. I've been though this before when the city of Richland tried to renege on their agreements with the Bridge Clubs about using the Community Center.
You can make a difference, and get long term changes for the better. But it's a long slog and there are very few winners, lots of dead bodies along the way. In our case, we eventually got more than we were asking for, but it was arduous.
Email is cheap, and it can help, but it only turns up the spotlight. What they CANNOT stand is 100 people or more, standing line only, wanting to get into a meeting so they can give their opinion. They look at you, you look at them. It's powerful. And Jo Ann is right, questions should be civil, and probably only one to 3 people actually at the mike during the meeting. The other 97 people are just window dressing, but they are very important. Each body is a personal statement, with eyes fixed on the board of governors.

One last thing. The RFP PROCESS(?) is the real culprit here. The ACBL, being non-profit is required by their charter to release an RFP for big ticket items.
Nicholas Hammond helped author the RFP. It was incomplete, partly because the ACBL wasn't sure exactly what they wanted. The documentation was incomplete, I guess because there was none. There should have been an exploration period, a back and forth between potential contractors and the ACBL so they could figure out exactly what they wanted, and what each contractor really had to offer. A shot in the dark proposal was not enough. Selecting contractors based on how pretty the proposal is doesn't work either. There should have been a bidding phase. There was none.


The RFP asked for cost and to be done in 9 months and Agile programming. The ACBL, in their wisdom, gave the contract to Nicholas Hammond, without checking out the other contractors, and the final contract violated many of the critical items in the RFP which Hammond helped write.

Nicholas is a beneficiary of a flawed process, and he has been done in by the same group that gave him a free pass the first time.

Nicholas is neither a sinner nor a saint. He is a business man, not a victim.



Dec. 28, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
All,
My understanding is that the technology committee is supposed to be independent. Hartman is obviously not independent. He should be allowed to present to the committee, but he should not be chair – or even a member.
I suggest you dash an Email out to your district director asking that Hartman recuse himself from the technology committee. One message, many people. It probably won't change things immediately, but if Hartman remains as chairman, the board of directors will notice.

districtnndirector@acbl.org

Dec. 27, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
I agree with most of the comments. Joe Hertz, in particular, really strikes home. Still..

I look at the 200,000 lines of the ACBLScore code, and the first thing I see are huge amounts of boiler plate on top of each module in which variables and routines are pre-declared before they are used. Many of the declarations are of little value to a programmer, because they refer to functions in other modules, but you can't tell which module the functions come from.

Most languages are not as rigid as Pascal – regarding declarations on top. And if I remember correctly, this “feature” can be turned off in Delphi. Either way, at least 15%? of the lines of code are analogous to boiler plate.
All through the code I see – if 32-bit Windows do this .. if DOS do that. If you cut out all the excess baggage devoted to DOS, lose another 15% of the code?
The GUI needs to be updated. The components seem feeble. Lopushinsky (sp?) must have written twice to four times the code that would be needed for modern visual components. In some cases, I saw almost 100 lines of code that would normally only take one or two lines with modern components. If we redo the GUI, is half the code gone by then?

Much of the code is devoted to Memory Management needed in early computers. Scrap that. If managing memory is still key, there are free downloadable add ins for Delphi that handle it automatically –or you can use Java, or whatever. Are we down to 40% left?

The database is a Turbo Pascal derivative. I'm not sure the game files should be pushed into a data base. Maybe converted to flat files which are automatically deleted after a month or two, or copied into an archive directory. The rest (anything that goes to ACBL) can reside in a conventional data base, which can be easily handled through SQL, LINQ, and transmitted via XML or JSON for those impressed by acronyms. If you carve that out, are we down to 60,000 lines of code?

Apparently printers was a real problem for the era, and they require a lot of code in ACBLScore. But those are handled pretty easily now by libraries and the operating system. Phsst! Gone.

There is some really arcane looking code that supports programs and macros that service ACBL headquarters, but they could be partitioned off from the first round of development while improving ACBLScore. Same for the programs that supports floppy disks, Windows 95?, Vista?

The GUI looks more complicated than it needs to be. Most of the 20 dialog boxes that pop up when starting up a game can be reduced to combo boxes on one or two forms.

The test code is intertwined and probably should be separated out and handled more discretely. A more extensive log file would be helpful.

The code is not spaghetti code. Jim was a strong believer in “say it once”. The problem is he never put in comments, not even a hint as to where things were being said. You see function XYZ( a, b, c) and wonder what it does, where it resides, and you have no clue. It would be easier with a debugger, or perhaps a text search tool that can search through many hundreds of text files all at the same time.

If you redo the GUI, replace the database, and use modern components, the 200,000 line program shrinks to the equivalent of 40,000 lines?

I'm interested in Club Games. I'm a club manager/director. If it was my project, I would have started small, improved the club game functionality first (because that's where my interest lies), and then used the new program as a platform to tackle tournaments and ACBL headquarters improvements later. You would have to be very careful however, to sketch out a broad design for tournaments and Headquarters first, so that you don't hard code in a design flaw while developing the club game stuff.

What is left after we throw out the junk, redo the GUI, and partition away headquarters code, and simplify the “Tournament/club mode” code? Not much. Movements, reports, computing master points, and entering results.

Movements are kept in tables, and the code is small and seems workable. Jim created templates for the reports, soft of a home grown version of Crystal reports. Computing master points is complex, but when Jim was writing code for these kinds of things, he was actually pretty straight forward (except in his use of the database). He did have a tendency sometimes to compute data for reports as he was printing them, and while inserting and deleting things out of the database, which bothers me, but that part can be restructured.

The program doesn't have to be of a monolithic design. Sending results out to mobile phones and Internet is different than ACBLScore for clubs, which might be operating minus an Internet Connection, and for clubs which might still be using travelers, and thus require hyper speed keyboard entry near the end of the game.

ACBLScore isn't the only horse in town. There are programs in Europe that can do many things that ACBLScore can't, such as running a Swiss team event coupled with Bridge Mates. Has ACBL talked to those people? Did Nicholas encourage them too?

I recognize that no one can succeed if the customer isn't willing to do his part. It's impossible.

And I realize that Nicholas Hammond did much more than what I have outlined – and perhaps $2 Million was a bargain for what he did. But what Nicholas has done sounds a bit like scope creep to me. Were the specs asking him to do this? Such tasks were certainly not in the RFP.

Nicholas Hammond accepted the mantle of Program Manager. How can an outside contractor act as Program Manager for an ACBL project? Isn't there a conflict here?

How can a project that uses Agile techniques wait 2 years for the first release? Is that even possible?

The RFP and subsequent (non) bidding process suggests to me that a naive customer was relying on Nicholas Hammond to act as the only adult on the block. The problem is, adults gotta feed the kids, and they don't like to lose projects by insisting that the customer do his part as well.
Dec. 26, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
Bud,
I get the most grief for Howell movements. Using ACBLScore, ask for one less round than normal, for each extra stationary pair you wish to accommodate – per Gordon Bower's comment.


If you end up with something that looks like a Mitchell, with all the cripples one way, that's probably not good. But you can use arrow switches to create a one winner movement and that should work out better. (Look them up on the Internet). Surprisingly, for 8 tables, you only should arrow switch one or two times per session to be optimum.



Dec. 25, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
I must really be getting old. I have so much wisdom to dispense. I guess this makes me a wise guy.

The only thing I know for sure is that “I think therefore I am”. But I'm not sure what that means.

ACBLScore and the Empire State Building do have a lot in common. You have to get high to really appreciate them.

If you want to understand the “spirit” of a contract, take it to a seance.

Show me a project with lots of creeping scope, and I'll show you a zombie – soon to be a corpse.

The user is the only thing that matters when developing software. Technology is not a user feature. Cost is.

Some people believe that “Any truck is a great truck, as long as it's a Ford and it drives around in a browser.” But that's not true. Trucks can't fit in a browser.

According to TIOBE, Delphi/Object Oriented Pascal jumped in importance to #11, in October, based on web activity. It is one notch below SQL, which dropped to #10. Java Script dropped two notches to 12. Ruby dropped 3 notches and now it is 16th. Delphi may be dead, but at least it's organic. Maybe it's the Halloween factor.

The moment my Unit Directory goes to press, it is outdated. A fact of life. If it takes 1 year to finish a software project, you are now 1 year out of date.

Many modern data bases are driven by SQL, but LINQ is more productive, and may become the data language of the future. I don't know.

At one time, object oriented databases were considered the wave of the future. A directory of ACBLScore game files is, in a sense, an example of an object oriented database. But now the design is “out of date”.

XML schema are cool. They come with almost no development cost with Visual Studios if you have an Entity Data Relationship diagram. Every project should have one.

But now JSON is the cool thing. XML is dead?

Databases and object oriented programming do have an “impedance mismatch” problem (that's an electrical engineering term). Microsoft is addressing this in VB and C# along with LINQ by developing the Entity Relationship framework. This doesn't mean that you should run out and buy these languages to be forward thinking. In my mind, it always has been a crap shoot, and may still be for quite a while.

If you insist on always using freeware for your million dollar projects, at least you'll get what you pay for.

I'm not trying to be rude. I would just like to point out that sometimes we have to objectively measure pluses and minuses before jumping into a boat. My wife gets mad at me, because the only way I know how to compare dis-congruent items is to think in terms of money.

This is not a pitch for any particular path forward. It is a smart ass arrogant plug for humility and discipline when we consider our options in the future.

Happy post Halloween.




Nov. 2, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
Yes, I like the BBO magic very much. It truly is magic. Did they start out with Browser technology? If my memory serves me correctly, they didn't. But that's probably not relevant. Point well taken.

Someone mentioned “forward thinking”, saying this project will have to last another 20 years.

Okay, true confession time. If the next 20 years is anything like the last 20, I won't know my name at the conclusion of two more decades, let alone what state I'm in, and 90% of all bridge players will be dead.

And if past is prologue to future, software technology will accelerate and change at even a faster pace, and all programmers will be robots.

I've made 3 big predictions in my life (perhaps more).

1) Government spending would lead to hyperinflation – I'm still waiting.

2). Gas would soon cost $10 a gallon. Still waiting for that one too.

Both predictions have taught me is that tomorrow unfolds in its own unpredictable fashion. And what you think will happen tomorrow aint necessarily so. In the long term, I think my first two predictions are right – even if it will take another 20 years before they are validated.

Even the most sure footed of trends sometimes take longer than you might think. And short term trends are almost unpredictable. It would have been a mistake to sell my Toyota 5 years ago and trade it in for a wind mill powered motorcycle. Luckily for me, there were no such vehicles to buy.

So, if omniscient robots will do all the programming in the future, how will code be delivered? I think it will be tailored to the hardware at hand. Perhaps browsers will eventually fade away. Or perhaps browsers are with us for all eternity for security reasons. I don't want to stake a million dollars on it, one way or another.

I was right on my 3rd prediction. I sent Emails every 6 months to Knoll and Hartman predicting that after 2 to 2 1/2 years they would have spent 1 to 2 million dollars on ACBLScore+ and have gotten nothing in return. I'm one out of 3.

I thought the 3rd prediction was as obvious as the first two, because I've seen the Big Bang Theory of Software development for legacy systems. It always comes out poorly. (I say that, and the next software project will come along to prove me wrong).

I'm a strong believer in open, incremental software development. As long as a piece of code is usable, use it, while slowly replacing the more obsolete code with newer technology. Hybrid browser technology working with code that is platform dependent is not unthinkable.

In my mind, that is “forward thinking” – to recognize that I don't know what I'm going to be thinking tomorrow. And as long as we keep moving in the right direction, considering real life cost constraints, we're moving forward.

The RFP process did not allow for this kind of approach. It almost mandated a “Big Bang” outcome. The fix was in before the proposal was made. And if the fix was in, why did they even ask for proposals?

I'm going to make one last statement and then drop out of this discussion. The ACBL has forked over $1.5M to build a “technology workbench”. Our proposal was dismissed as not being forward thinking. But now the ACBL is doing exactly what we suggested – moving ahead incrementally with the existing code. So I guess we were 2 1/2 years ahead of our time, even though our proposal was clearly behind the curve and was properly dismissed without pause for thought.

My concern is that the same people who gave you ACBLScore+ are still taking your money at Sectionals and Regionals so they can catch up with the $1.5M that has already been spent. So I guess that puts us even further behind the curve.






















Oct. 26, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
Actually,
Delph/Free Pascal/Xaramin support almost all platforms. You can see the lists on their web sites. They have cross compilers for almost all mobile devices, whatever that means. But as I've said before, one GUI that fits all devices is pure fiction.

I read the “spirit”of the proposal as wanting a better GUI – without specifying what that might mean. Personally, I thought the RFP was flawed.

If the RFP wanted a certain kind of technology, they should have stated such. What they actually asked for was a program that duplicated ACBLScore functionality that went on a Mac. And I guess if your name is Hammond, and you were a primary author of the RFP, it is only natural that you get the project, because you are the only one who understands the RFP. I sure didn't understand it.

If I was on the committee, Hammond would have been disqualified because of conflict of interest issues.

So here is where we part ways. I think programming is something you gut out, no matter what language or operating system or environment you're in. There is no magic bullet. Just newer ones.

Magic bullets were in fact the spirit of the RFP. But magic only works in fairy tales. Magic doesn't work if you have to pay the bills like everyone else.






Oct. 26, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
Greg,
I don't deny that the landscape is changing quickly. But if I read you correctly, you're assuming that machine hosted code is not keeping pace with advances in browser technology. Neither side is stagnant. For example, they are moving programs onto the cloud that update machine resident code automatically. Perhaps without the user even noticing. There are entire companies devoted to developing tools to provide cross platform support. They haven't heard that they're dinosaurs, yet, and about to go bankrupt. The tools do cost money – but here is the irony. For legacy code, they cost a lot less than moving into a browser.

Consider the following. The original proposal was to move ACBLScore to a Mac. That was the big item.

Here is one approach. Bite the bullet, let Embarcadero/Delphi bleed you for their tools. Maybe $40K total per year. Use their Mac Cross Compiler. If you're very lucky, done in a month. Their code also links into SQL Server quite handily.

If you don't like Embarcadero, go to Freeware and use Free Pascal (a free version of Delphi). They have cross compilers for most platforms as well.

Total cost? I can't see why $100K is not reasonable if things go swimmingly. But software never does, so lets say $300K.

So to port to the Mac will cost us $300K if we stay with machine resident code. If we don't port to the Mac, we are done, and presumably we have saved $300K. There is nothing basically wrong with the current program. In this case, moving to a Mac costs us a gazillion percent increase in the project, because that was the primary task. Admittedly, that's an unfair comparison.

Let's say we have a better idea. Move all the code to a browser. Cost – $1.5M and counting. I'm not sure Nicholas did anything basically wrong. I think someone had a preconceived notion about browsers and didn't consider all the alternatives.

$300K versus $1.5M. I don't see how the browser is an automatic choice.

I have my own biases. I have yet to see a browser app I like that can take key strokes as quickly as ACBLScore must function at the end of a club game if the director does not have bridge mates available. I do admit, I'm not a browser guy.






Oct. 26, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
Some people just don't know when to shut up (that's me).

In response to Ed Reppert. I hate Microsoft. Still I don't own a mAC (or is it Mac?)

Macs are good, but I think most software developers underestimate the cost of running on a 2nd platform, until they've had to do it.
Without going into a discussion of the 6 different options for cross platform development to show how smart I am, I estimate that a 2nd platform ultimately costs a large project another 40% on an ongoing basis. If you don't believe me (and who would) there is a book on the subject “Cross Platform Development for C++” and it is 300 pages long. There's always Java, but if you go out on the Blogs, Java is not the Holy Grail either – especially if you don't trust Oracle and Larry Ellison.
I'm not pushing one way or another, but I think the decision is far from trivial. And there is always the option of running a version of Windows on the Mac. It might be cheaper than the alternatives.

In response to Corey. Yes, if a consultant offers to charge $100 an hour he might be worth it. If he charges $50 an hour, he is obviously a half wit. And if he's a retired Senior willing to do it for free, he's not worth a wit.

It's hard to know who to take seriously. One study found that most managers do not do any better at hiring the best people than a roulette wheel, and the best predictor of whether someone would be hired was if they had common hobbies with the boss.

I was reading about a company that has developed a video game. You give this game to all job candidates. They play it for 30 minutes, and it can tell you all about the persons strengths and weaknesses. And apparently it is dynamite at picking out successful entrepreneurs and project managers. Maybe the ACBL should buy one.



Oct. 26, 2014
You are ignoring the author of this comment. Click to temporarily show the comment.
I am a retired Delphi, Assembler, Object Oriented Pascal, Turbo Pascal, SQL Server, Access programmer/Project Manager/Engineering Director.
We offered to meet the original RFP by the end of 2012 for between $100 to $300K depending on further clarification from the ACBL, about what they wanted exactly.
I'm also a Gold Life Master, Club Director, Teacher, and Club Manager. My domain knowledge is excellent. The team I had put together for help on the proposal consisted of 2 PHD programmers in Computer Science, 3 with Master Degrees, and a local company that does web development.

I live in Richland Washington, home of the “Bombers”. The high school mascot is a mock up of the atomic bomb, which they carry around to all athletic events. And their logo/symbol is a mushroom shaped cloud. They always felt that rather than be a “Vandal”, a “Blue Devil”, a “Bull Dog”, or a “Lion”, if they were going to kill people with their football and basketball team they might as well be expedient. I mention this because this is an engineering town (Pacific Northwest National Labs run by Battelle) and there are many smart people here, and lots of engineering interns that work on the cheap.
Our first proposal was a shot in the dark, because quite frankly the RFP was odd and suspicious. Why would anyone want an expensive rewrite of a program, so that it could do what it already does? Also, the idea of writing one program that plays on all platforms is a myth. Windows programs should look like Windows programs. Apple programs should look like Apple programs, and phones have a small screen and require an entirely different looking GUI. We waited for clarification and a 2nd round of bidding, but we didn't even get the courtesy of an EMail.

Do we really need ACBLScore to run on a MAC and iPhone? At $1.5M and counting, I don't think it's required. Clubs are now buying Bridge Mates, Dealing Machines, and all sorts of stuff. A crude Windows computer is not a deal killer for a club.

Browser based technology is inordinately expensive, especially for ACBLScore. Do you like the new ACBL browser based “Learn to Play Bridge”? I don't. It's slow and leaves you anxious to click on the red X close button.

If you have a Windows based program of ACBLScore on your computer, you'll notice that the program consists of a basket of Windows executable files. I could write a program in 3 weeks that would surround the executable files and provide additional capability. Further more, Delphi understands COM. It would have been a piece of cake to add hooks into the program through COM, or any of 10 other ways, and use the hooks to talk to the existing file structure and all of the existing code. 2 Years? How about 6 months.

And what is so special about SQL? As a director, I'm glad that I can copy the game files and move them from computer to computer. I don't disagree that perhaps ACBL wanted to keep all the data secret, but that's just paranoia. Some of the information is better off secret. But text files, when appropriate, can help both the programmer and the user.

I have a copy of the ACBLScore source code on my computer (or at least a great majority of the code). And eventually I will write a program that understands the existing file structure of ACBLScore. It will also know how to talk to Brigemates in a more robust fashion, how to match up players for Swiss Events, how to show scores and opening leads on the recap sheet (we already have automated that process here in Richland) and it will also be able to run Individual and Swiss Events from Bridgemates with more grace than we presently have.

In short, the program will do everything that ACBLScore does, and more. It won't cost much of my time. But it is too bad that the ACBL is so incestuous. This program will have to be developed externally without any constructive input from the ACBL. And that's the real tragedy.








Oct. 25, 2014
Larry Lang edited this comment Oct. 25, 2014
1 2 3 4 5 6 7 8 9 10 11 12 13 14
.

Bottom Home Top