Party's Deal-Making Software a Flawed Application

I was sweating the final table of last night's this morning's "Deep-Stack Disconnection," a.k.a. the FTOPS Main Event, when I remembered that I had a little bit of oddball news saved up, with a supporting image grab. Sometime ago I tossed out a little blurpette about Party Poker's deal-making software having a hiccup that might have shifted payouts by a thousand or two in the $200,000 Guarantee back on Christmas Eve. I've now seen the same thing two more times, occurring in exactly the same way, and I'm convinced of it: Party's deal-making software has a pretty big bug.

If you're reading this in the States, you likely don't give a rat's ass, of course, but still, it's one of those things that's interesting for its own sake. Party spent some big bucks developing the deal-making system, and for all the hype, one could expect it to work perfectly. But it doesn't.

Here's how the bug unfolds:

1) The surviving players are noodling around with the idea of a chop as a break looms, which happens frequently;

2) The players agree to discuss terms sometime during the break, and they all click their "Deal" option buttons over to "Yes";

3) The break ends, and even though the software recognizes that the players want to discuss a chop, it starts dealing the first hand after the break, which always has increased blinds, too;

4) The players collectively say, "What the hell?" In most instances, there is little or no action on this hand; it's folded around to the big blind or a single pre-flop raise takes it down;

5) The players' chip counts change as a result of the hand that was dealt;

6) The software then enters deal-making mode, but does so with the chip counts as they existed before the previous hand, meaning as they were at the break;

7) The players scratch their heads again, and usually exit the deal-making algorithm, recognizing that the totals being used by the deal-making process don't match what they can see on their screens;

8) A second post-break hand is dealt, which changes the chip countsn again, and during this hand the players usually choose to re-enter the deal-making the process;

9) After this second hand, the second trip into the deal-making software now picks up the ocrrect chip-count totals, and a deal is usually struck. However, two hands have been forced to be played after the players themselves wanted to make a deal, and so the program itself has forced a change in the totals onto the players. This isn't how a deal is supposed to work.

I wouldn't expect you to take my word for it without some sort of proof, so here are images of the disparity illustrated above. These two images display what the chip counts actually were at the end of the hand and, moments later, once the flawed part of the deal-making process has occurred:




Compare the chip counts for the players from one image to the other, and you'll see that they don't match. This is because of the program bug. In this case some big dollars were at stake, meaning that the bug itself could have impacted the potential deal by hundreds of dollars, if not more, and it of course raises the possibility that the flaw itself has kiboshed some deals in other tourneys that the players themselves were ready to make.

Interesting stuff. If I ever see evidence that it's been fixed, I'll let you know....