Coming in the next Poker Copilot update: When relevant, Poker Copilot will show your all-in equity % for the previous hand. So now when you lose with Pocket Jacks to a villain who hit his flush draw, you can immediately see if, despite the loss, you made the correct decision in terms of equity.
With the help of loyal but frustrated Poker Copilot customer Artem, I’ve been able to tune up Poker Copilot’s HUD to make it faster and more responsive for people with extremely large databases. The next update will have these improvements.
A brief overview of the improvements:
Imagine you’ve got 500,000 hands of 6-max PokerStars No Limit Hold’em tournament hands in your database. For each hand, Poker Copilot records roughly 60 statistic data points. When you are playing, and the HUD is showing, your own HUD stats are calculated by aggregating 500,000 hands times 60 data points = 30 million data points. That’s a lot of data to recalculate after each hand on each table. The database that Poker Copilot stores this data in is optimised to handle such cases quickly, using database indexes and pre-rolled-up summary tables.
A new database index
Except, that Poker Copilot has stopped using the optimisations, if you had “HUD stat weighting” turned on. Somewhere over the development of Poker Copilot 5, as we changed things around to facilitate the addition of HUD statistic weighting, the database index setup stopped helping for tournament live play. So Poker Copilot was doing more work than necessary to calculate your own statistics. (HUD statistic weighting is a Poker Copilot 5 feature where more recent hands count more towards calculating statistics than older hands do.) We added a new database index designed for optimising fetching the right hands for calculating tournament HUD stats.
HUD stat weighting for opponents only
But there was another improvement waiting for us: the idea of HUD statistic weighting is not so useful for your own stats. And yet HUD statistic weighting was part of the performance problems. It is intended to make sure your opponents’ stats are more weighted by recent hands. Your opponents’ stats are what you typically use for making decisions on the poker tables. Your own stats are not used so much at the tables during live play for decision making. So we’ve turned off HUD statistic weighting for your own stats. It now only affects opponent stats. You will typically only have a fraction of data for any specific opponent, so it is much quicker to weight newer statistics for opponents than it is to weight your own statistics.
Don’t calculate what you don’t need
Poker Copilot was calculating hero stats even if hero HUD stats were set to “Don’t show”. That was rather pointless. The quickest database query is the one that isn’t performed. So we’ve made Poker Copilot be smarter in choosing what data it fetches during live play.
Hopefully these three changes will make Poker Copilot quicker for you when using the HUD with a massive database.
This update has many small tweaks and fixes. The most important changes are:
Fix: The HUD works again on Merge Network rooms, including CarbonPoker, Players Only, and Sportsbook Poker. Due to changes to their software, we can no longer automatically detect your preferred seat on these rooms. You’ll need to set your preferred seat in Poker Copilot’s preferences -> “Poker Room” -> “Merge Network” -> “Preferred Seat”.
Fix: 888poker.es now supported.
Fix: 888 poker hands no longer crash the hand replayer.
Fix: 888 poker hands no longer crash the HUD.
Fix: Fetching seat info from SharkScope for Winamax now works on multi-table tournaments.
Change: Revised “fold to 3-bet” statistic so that it only includes the situations where you made the initial raise.
Fix: Revolution Network 10-max tables were sometimes identified as 9-max, breaking the HUD
Fix: Winamax tournament wins that have both a cash component AND a ticket are now correctly imported
This update introduces a new service for customers who have a SharkScope account linked to Poker Copilot. On tournaments on PokerStars and Winamax, player names are automatically fetched from SharkScope’s website before play starts, already showing player info before the first hand.
You’ll see SharkScope stats for each player, and – if you already have data for a player – you’ll see Poker Copilot stats too.
This is also handy when changing tables in a tournament. Within a few seconds of being moved, Poker Copilot will fetch enough info from SharkScope to be able to show you stats for each player. You shouldn’t need to wait for a hand to be completed.
We’ve been getting occasional reports from Poker Copilot 5 users that the HUD is not updating for long periods. Until now we’ve been unable to reproduce it.
Then two days ago, a set of coincidences let me experience the bug. The HUD would show after one hand but then it wouldn’t update. The hardest part of fixing bugs is reproducing them. Once you’ve reproduced a bug, fixing it is usually straight forward. Time consuming possibly, but straight forward.
Here’s the bug: if you have a recently created or modified file in one of your hand history folders that ISN’T recognized by Poker Copilot as a valid hand history file, then any live hand history file subsequently detected by Poker Copilot only gets handled once. Future updates are ignored until you restart Poker Copilot, or one hour has passed since the file causing the problem was last changed.
So yesterday I fixed the bug. There will be a Poker Copilot release later today that includes the fix.
I wanted to know how this critical bug got into Poker Copilot. It turns out that I added it in May, 2014, in the early days of creating Poker Copilot 5. It was a small optimisation needed for our work in making Poker Copilot capable of running on Windows.
May, 2014…and I’m writing in March, 2015. In that period I’ve had a dedicated part-time QA assistant working for months testing Poker Copilot thoroughly, many other bugs have been discovered and fixed, we’ve gone through a long beta period, we released Poker Copilot 5 two months ago, and this critical bug managed to keep hiding.
This makes me ask myself: what could have prevented this?
Unit testing? I don’t think so. Poker Copilot already has hundreds of unit tests. The component where this bug occurred is not a natural candidate for unit testing. It is not good to make unit tests complicated and slow. When unit tests run slowly it becomes tempting not to use them frequently. I think that adding a unit test that would pick up this bug would be too convoluted. Unit tests, in my opinion, are best used to test black boxes, and this critical bug was in code that doesn’t easily lend itself to be a black box.
Code reviews? In a code review session, another developer would have looked at my change back in May, 2014, and would have quickly spotted the bug. It was an egregious bug. But as the sole developer in my company, I don’t have the luxury of code reviews. I wish I did.
Shorter release cycles? Many months passed between me creating the bug and fully releasing the code. I believe that if I had released a Poker Copilot a week or two after adding the bug, I would have been able to connect the “my poker copilot is broken!” feedback to guilty code changes much quicker. Customers would soon report the problem started with the latest minor update, I’d look at what changed in the latest minor update, and would have been able to narrow down the problem with too much trouble.
This bug isn’t alone. A month ago I discovered another long-hidden performance problem. Despite accurate reports from customers, I only managed to reproduce it by getting a helpful customer to supply both his Poker Copilot database and his Poker Copilot preferences file. That helped me spot the problem – again, the offending code had been part of Poker Copilot 5 for many months, making it through near daily testing for months, through the beta period, and into our actual release of Poker Copilot 5.
Software with infrequent major updates
The more I experience problems with major updates, the more I believe it is time to end for good the 12- to 24-month major upgrade cycle that desktop software traditionally uses. Releasing many small upgrades frequently is much safer than releasing a huge upgrade seldomly.
This is is no remarkable observation; since 2010, Google Chrome has six-week release cycles. Mozilla Firefox switched to six-week release cycles in 2011. Only three years ago, Facebook announced a four-to-eight week release cycle for its mobile apps. Now it seems to be every two weeks. From their iOS app description: “To make our app better for you, we bring updates to the App Store every 2 weeks.”
On the other hand, Apple releases OS X yearly. As a developer I’m always amongst the first to update to the new release, and it is always initially a painful process. Things that used to work stop working. (For some months OS X Yosemite turned my lovely Sennheiser wireless headphones into expensive dust collectors; and my Apple TV became more trouble than it was worth to use from a Mac with Yosemite. Apple rectified these issues over some months.) Parallels Desktop, software I rely on for running virtual machines – an important part of modern cross-platform, cross-version software development and testing – released an update some months ago that worked worse than the previous version – but required me to pay an upgrade fee. I had to pay money to have what seemed an inferior product. Parallels Desktop 10 did have some helpful new features, but all I could see at first was that the new update was worse for me than the old one. Eventually they released a couple of minor updates and the problems were solved.
The difference between Chrome, Firefox, and Facebook on one hand, and Poker Copilot on the other, is, well, a lot. Two major ones for the sake of this article: they have many more resources; and their products are free. So their release cycle doesn’t have to take into account how frequent free releases rather than an annual or twice-yearly paid update affect sales and profitability.
Poker Copilot is a paid product. After a few years on the market, upgrade fees become a significant source of revenue for desktop apps. This is why having a occasional major upgrade of Poker Copilot is important for my business.
Yet customers expect significant extra value for the hassle and expense of major upgrades. So it is tempting to develop for many months, and then release a major upgrade. At release time, we can say, “Look at these new features if you pay to upgrade!” But, as my experience has shown, this leads to software that has more defects than is the case with many minor updates. As I noted with Parallel Desktops, some Poker Copilot 5 customers could say at first: I had to pay money to have what seemed an inferior product. I believe Poker Copilot 5 to be a big step forward, but for customers who were affected by initial bugs, and who didn’t need or care for the new changes, all they could see is that it brought them problems. This is a stressful situation for me; it isn’t pleasant to be trying to deal with this. The bugs causing customers grief are hard to find. While finding them, I’m not able to work on new features nor on other products. Nor rest on a sunny beach, which is always a pleasant alternative.
One way to solve this is to create subscription-based services, either for desktop software, or for online web applications. People pay a monthly- or annual- fee. While they keep paying, they get to keep using the software. When they stop paying, they can no longer use the software. Instead of major updates to get customers to pay upgrade fees, the company releases frequent small updates, to keep the customers subscribing. That is not a path I intend to follow at this stage, although it certainly is an option worth investigating.
Another way is to state clearly that a purchase of desktop software entitles the customer to the current version and all upgrades for a time period, say one year. After that time, the customer can still use the version they have, but they can no longer update to new versions without buying an upgrade license. I believe this to be more customer-friendly; the customer doesn’t feel they are forced to buy upgrades. They only do so if they believe there is value for them in the new major upgrade.
A friend of mine reckons that it is inevitable that one day Poker Copilot – and indeed most desktop software – will become an “in-the-cloud” pay-by-month service. If that is the case, I think we are still a long way from that day. Due to the massive databases that some Poker Copilot customers have, and the processor demands a database-heavy product places on a computer, I’d like to avoid that change for as long as possible.
For now, after the headaches in the last 2 months of fixing the critical problems introduced in Poker Copilot 5, all I can think is: No more major Poker Copilot updates ever; frequent minor updates from here on. The end product is the same; the path to get there is more pleasant for me and for my customers.
