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.
We recently changed the maximum spots available in Poker Copilot’s HUD for showing statistics. It used to be a 4×4 grid; it is now a 5×5 grid. This gives you up to 25 statistics.
We hope to soon increase the choice of statistics you can put into those 25 spots.
I’m in a hotel room in Laos; the Chinese New Year starts in a couple of hours. That seemed like a perfect time and place to answer a question nobody had asked until yesterday: what email companies do Poker Copilot customers use?
Why is this a question? It’s because customers who use hotmail.fr often don’t receive the email we send with license key info. Hotmail.fr enthusatiatically decides that our messages are spam and often our French customers who use hotmail.fr are denied the chance to receive their license key. While talking about this with Alex, our QA guy, we asked ourselves how many people actually use hotmail.fr, whether the number is dropping, and whether we should spend much time working out what exactly is causing this problem.
Gmail dominates, being used by more people than hotmail and yahoo combined.
But 3% for me.com and 2% for mac.com? Those numbers look odd. Because me.com and mac.com are two obsolete attempts from apple to do what’s now called cloud computing for consumers. Both have been replaced with iCloud. Clearly this data is unduly influenced by an older state of affairs. Nothing stays still on the Internet; what’s relevant information for five years ago is misleading for today.
So let’s only look at data for the last twelve months. Let me work out the syntax in MySql for date comparisons…I never recall the specific way to do this for a particular SQL engine. Ah, here it is.
So gmail.com has gained, but hotmail.fr together still have a significant 6%. So, it seems it is worthwhile making the changes that will make hotmail co-operate better with our license key emails.
(Aside: it makes me kind of sad that gmail.com keeps moving ahead. It is getting dangerously close to monopoly status, and who can compete against a massive company that offers an excellent email service for free? I use gmail myself, but still feel something is not good with this market domination.)
—
Postscript: I asked Margherita, our customer support agent if this problem was still happening: were hotmail.fr addresses still filtering our license key emails as spam? It turns out this is no longer happening. Well, there was a bunch of investigation and writing that turned out to be unnecessary!
We’ve had lots of people report yesterday and today that Poker Copilot is not working with Winamax Poker ever since the most recent Winamax Poker update.
The strange thing is: when I try, the HUD shows quickly and accurately on Winamax. I’ve tried ring games and tournaments.
If you have any info that will help me reproduce this problem and solve it, please let me know directly at steve@pokercopilot.com.
Have you found that on certain tournament types the HUD doesn’t work? Or on certain cash games?
I’ll be very grateful, as will many other Poker Copilot users who play on Winamax.
From today (Jan 30th, 2015) until February 14th, 2015, we are going to brazenly bribe you to buy or upgrade to Poker Copilot 5.
We’ve introduced a 20% discount for everybody. Simply go to our online store, and you’ll see the 20% discount automatically applied:
Prefer euros? The same discount applies:
That’s the full edition of Poker Copilot, with Hold’em support and Omaha support. All features are included, at all stake levels. This is no “small stakes” edition.
tl;dr: Poker Copilot 5 includes full Omaha support for all customers.
For a while, we charged a little extra to get Poker Copilot with Omaha support. This was in line with the “up-sell” model that many sales and marketing experts tell us small business owners we should be doing. “Capturing consumer surplus” and “price discrimination” are the rather strange names given to this practice.
However I was never really happy with the increased complication it added. I hate it when I decide to buy a product, then go to the sales options, and find I now need to work out which edition of a product I want to buy. Especially when, with software, it is obvious that the only difference between two editions is usually a set of “if-then-else” code statements.
So with the introduction of Poker Copilot 5 (which you can download from our home page) I’ve gone back to the “one edition to rule them all” approach. There is only one edition of Poker Copilot 5; it includes Hold’em support and Omaha support. So long, “price discrimination”.
Upgrade to Poker Copilot 5 from any earlier edition of Poker Copilot and you get full Omaha support.
Here are some benefits of this decision:
Now our purchase page is simpler. You have only one, clear, obvious, easy-to-make decision: are you buying Poker Copilot for the first time? If so, then buy the full edition. Otherwise buy the upgrade. Both paths lead to the same destination.
Our customer support is easier. When someone reports a problem with Poker Copilot, we no longer need to work out whether that is because Omaha is not enabled.
Our software registration logic is simpler. As well as the code through Poker Copilot that used to artificially limit options based on license key. Simpler code typically equates to less bugs.
Perhaps when my company gets to be comparable in size to Microsoft, I’ll reconsider this approach. But until then, I think I prefer simplicity for my team, and simplicity for my customers.
If you have a Retina screen, such as what you find on a modern MacBook Pro, then you’ll notice that the text and icons on Poker Copilot 5 look much sharper than Poker Copilot 4. We’ve changed all the text to use a better typeface for Retina; we’ve created Retina versions of all our icons; we’ve made the necessary changes for the replayer and other screens to look as high-definition as possible.
Today I realised there was one gap in our Retina improvements: the charts weren’t so good. I had never noticed before, but suddenly I couldn’t help but notice how blurry the text on the charts is compared to the text elsewhere in the app.
So I fixed it. Here’s a “before” shot and an “after” shot.
These improvements will be in the next update of Poker Copilot.
