I had a lot of fun attending a Lean Poker event last weekend!

It’s a type of event where programmers get together, form teams and spend the day writing code competitively, to see who can write the best automated online-poker player. We don’t play for money but for pride, and the main aim is to practise writing beautiful code and lean principles. That said, given the time constraint of a single day, the focus is usually on Deliver as fast as possible and by the end I’m flurrying around to keep errors out of the code. We try to get quick feedback during the day (more on that later) but I thought I’d do a write up about the event to give people who haven’t attended one of these before an idea of what it’s like!

How it works

As I already mentioned, the point of Lean Poker is to create an opportunity to practise lean principles and write beautiful code where the usual pressure of professional responsibility is substituted by friendly competitiveness. Tied with the tension and thrill of poker playing makes the programming you do here much more fun than what you’ll likely do at work.

Lean principles were originally developed at Toyota to improve production but they have been applied to many other areas since then, including software development, where it’s usually considered part of Agile development. Agile is known for such practices as early deliver and continuous delivery, as well as fast response to changes in requirements in contrast to traditional methods of development, which typically involve lots of planning and documentation up front, before any code is written or even adding an online signature with services from the sodapdf.com. Lean development itself involves fast delivery, learning from trying and avoiding unnecessary bureaucracy, requirements, code or anything which might slow down the process. Indeed, for our poker player, deploying our code before anyone else is the most important in getting a head start!

the point of Lean Poker is to create an opportunity to practise lean principles and write beautiful code

Lean Poker in Budapest is organised by the Coderetreat Budapest meetup group. The event usually goes from 9 o’clock to 6 with a longer break in between for lunch. The first half an hour is spent revising poker rules before picking programming languages, teams and diving straight in. The time is split up into 60 minute coding blocks. These are followed by a retrospective session where all the teams stand up together and share what they learnt in the last round, and then some time away from the computer, winding down, having a snack or getting some fresh air before the next round starts. The poker tournament runs non-stop, several times a minute, during the coding sessions, so the principle of fast and continuous delivery really applies here because a delay in putting out an improvement could give others a chance to step on us to the top, or an error in the code left out for just a few seconds could pull us all the way down to the bottom. The speed with which stuff needs to get done means that during coding sessions we really cut out unnecessary chit-chat and stubborn disagreements about which style of writing is better, and work together to get a better program into the tournament with every passing minute. This makes the event really fast-paced and exciting, and in the retrospective we sometimes have a good laugh at the clumsy mistakes we made in our haste.

Our own code

I made a team with a couple of colleagues from work, we’re all relatively new there, so it was also team building in a way. To allow us to focus on the poker logic instead of wasting half the day implementing a RESTful HTTP client, we’re provided with skeleton code implementing a folding player. We picked JavaScript and its Skeleton player is here. We named our bot ‘zsozsó’, Hungarian slang for money –like dough in English– and also the name of our company mascot.

In the game, you fold by returning a number lower than the current highest bet. Every team’s folding bot returns zero, so the first thing we do, is a high number. If the other teams are still sending zeros, they fold and you win. If they’re sending numbers but yours is bigger, then technically they’re still folding and you win. This head start gives you a few minutes to write some actual logic. In our rather crazy commit log you can see the first 2 commits just bump up our return value. During those 10 minutes we had a look at what’s in the HTTP request and started building functions to dynamically bet larger amounts than our opponents to stay in the game. We realised fairly early on that a mistake in the code could cause JavaScript to return NaN (Not a Number) instead of a number, hence we translated NaN into a valid bet amount:

if(isNaN(parseInt(bet))){
    bet = 500;
}

We also realised that returning any unexpected output in the response –including NaN, floats, unhandled exceptions and basically anything other than an integer– earns you negative points! Unfortunately right after a coding error introduced one of these, Heroku blocked us for request spamming while we were trying to deploy our fix and then GitHub went down for maintenance immediately afterwards!

First @heroku blocks us for request spamming on deploys. Then @github goes down for maintenance. This @LeanPoker is unusually special!

— Siôn le Roux (@sinisterstuf) March 21, 2015

After the harsh punishment for our mistake, the first thing we did was wrap the main function in a try-catch block which, combined with the isNaN check, ensured we always returned a number, even if it was 0! On the other hand, this could have been avoided altogether if we’d had better test coverage, so I personally spent the next couple of hours writing tests and hunting bugs while the rest of the team worked on the logic. I’m too embarrassed to say how much of that time was spent trying to figure out why the tests wouldn’t run at all: It turned out I had written “calulate” instead of “calculate”. 🙁 Another thing that took a lot of time was setting up a log drainer so we could inspect logs of our games, something which none of us were familiar with but Tim finally managed to figure it out and it paid off in the end. If you need logging for your poker player, you can save a lot of time by just making an account at paper trail and copying the generated URL into the Lean Poker dashboard.

a try-catch block, combined with the isNaN check, ensured we always returned a number

Silly mistakes aside, I think we did better than last time. Within the first session we split our betting and game logic out into separate files under “logic”. We also had a local copy of the JSON we get in the request; in Node.js you can import JSON files just like any JavaScript file, so we could include this as-is for sample data for our tests. The flow chart we’d sketched at the start was implemented fairly quickly and the rest of the day was spent fleshing it out with details, fixing small mistakes and tweaking the constants for betting amounts and card values. One of the other teams had the idea of putting their constants in a file on Dropbox so they could download that in-game and make tweaks to the deployed code because the 5 minute deploy blocks can be too slow for emergencies. The coolest thing I saw that day was when Bence chuckled at this and proceeded to build a live config editing API into our bot in a matter of seconds, allowing us to tweak our constants simply by sending requests to our player from the browser! I’m also happy our newest colleague Bogi joined us; our card evaluation and betting strategies are thanks to her.

function lowCards(cards) {
    // returns true if both cards below lame limit
    if (toNum(cards[0].rank) < lim && toNum(cards[1].rank) < lim) {
        return true
    } else {
        return false
    }
}

What I learnt

One of the Lean principles is to maximise learning and I must say I learnt a lot at this event. I learnt new techniques from my colleagues and it was fun to get to know each other outside of work. I also learnt from how we worked and got things done under competitive pressure where the deadline isn’t an arbitrary date but rather ASAP. One of the most useful things I learnt was that you really can get things done extremely fast if you have sufficient testing to let you move forward boldly without breaking things and if you skip everything which is not directly helping, like discussions about an ideal way of solving a problem that needs to be dealt with immediately. Having the safety net of tests also lets you learn fast by trying out several different things and seeing what works.

All in all I had a lot of fun and learnt a lot. Although our code is a bit messy from the time constraints, it is public and you can browse it here. There are also some photos of the event on the Code Retreat Budapest Facebook page. Lean poker is a fun way to practise lean principles and get to know people and I highly recommend it. Keep an eye out for Lean Poker on meetup.com and I’ll see you at the next event! 🙂