Here at Tyro Payments we’ve used Extreme Programming (XP) for over nine years. At the time, the decision to start using XP was a no-brainer for the team. One of our goals was to build a fast, stable, reliable EFTPOS network, and XP, with its focus on quality, seemed like the perfect process to help us achieve this goal. Over the last nine years, the XP practices have gone a long way to ensuring that our platform and products have been extremely reliable; Tyro processed over $5 billion in transactions this financial year and our systems barely missed a beat. We certainly weren’t plagued with any major outages that the big banks seem to be regularly hit with.

Two of the XP practices that have proven themselves invaluable have been TDD and Pair Programming. While TDD is relatively well understood and accepted these days, Pair Programming still stirs up some very emotional debates amongst its proponents and detractors. I’m not going to try and convince the detractors that it’s a great idea for every environment, but it has worked extremely well for us – especially so in the last 18 months. The engineering team has doubled in size in this time, and without pairing, I don’t believe we would have been able to bring new team members up to full productivity in the short time that we have, while also managing to avoid the spike in bugs usually associated with such rapid growth.

One of the other great principles of XP is the focus on continuous improvement, and while XP can be done “by the book”, the book itself encourages teams to tweak the process to suit the particular environment. Over the years we’ve dropped practices that we found added little to no value and modified others to suit our needs better. Our process is in constant review in our fortnightly retrospectives.

So it was on Monday this week when we found ourselves with almost half the team off sick with the nasty bug that’s doing the rounds of Sydney workplaces. Pairing opportunities were severely limited, and with numbers still way down on Tuesday, we had to take drastic measures to ensure our productivity and quality didn’t fall. We decided to trial a new XP practice that we’re calling “Bear Programming”. If you don’t have a pair for the day you can elect to use the services of our newest team member, Bear Pairington.


bear programming 2
Bear Pairington at daily stand-up

He might look cute and cuddly but he’s a gun programmer – as far as I know, he’s never been responsible for the introduction of a bug into any code. He won’t waste your day arguing about which design pattern or variable name to use, but he is the ultimate Rubber Duck (no offence meant Mr. Pairington). Bear will also gladly attend those annoying meetings with clients, business stakeholders, and pretty much any other meeting you’d rather not be in. Just one word of warning, and we’ve learnt this the hard way, do not under any circumstances try to convince Bear that weakly-typed languages are anything other than a blight on the software engineering profession. While Bear has a soft and fluffy demeanour, he will tear your head-off if you try and convince him that Javascript is a great solution to any problem.

So far, Bear has been a great asset to the team, but like experiment we’ll be monitoring his performance closely. We’ll keep you posted on how things pan out.