First Lions test — developer’s eye view
The first test between the New Zealand All Blacks and the British and Irish Lions took place this morning, with New Zealand coming out on top 30–15. As I was watching this a few tactics that could be applied to software development struck me. But first I’m going to indulge myself with some thoughts on the match — if that isn’t your thing you probably want to skip ahead.
New Zealand are the number 1 team in the world by a considerable margin, they’ve won their last 47 games at home and hadn’t been beaten at Eden Park since July 1994, so it was always going to be an uphill task. Typically they are at their most vulnerable, although that is an extremely relative term, at the beginning of a series when they haven’t played for a while, as was the case here. The B&I Lions are very much a scratch team, being made up of players from all the home nations that typically have only played against rather than alongside each other. In this situation it is much easier to get the defence and set piece sorted out, as they are much more structured, than the attack — just look at some of the smaller teams around the world like Italy and Argentina from a few years ago, typically very strong scrummaging and defending, but not so much to offer going forward.
The way to beat the All Blacks is typically to defend like mad and capitalise on any mistakes — Ireland produced a win at Soldier Field with these tactics. Unless you are Australia (although not for the last couple of years), when a world class back row and an incredibly talented attacking backline is often enough. Thing is the defence has to be relentless — drop concentration for a second and you will concede, as the Lions proved once from a penalty and once when they were expecting a penalty from the scrum. For 55 minutes the Lions managed this and at time New Zealand looked rattled. From the hour mark mistakes started creeping in and boy were they capitalised on. Sadly New Zealand will likely be a lot better in the next couple of tests, so the Lions really have to step up.
Lessons for developers
Keep it simple
Rugby is often referred to as a simple game, and New Zealand personify this. There’s very little, if any, complex back moves or training ground tricks in the lineout. They play a simple game, and do the basics well. The difference between New Zealand and every other team in the world is execution — clinical doesn’t do it justice, they hardly ever make mistakes. Eventually the opposition make mistakes, gaps open up and the the execution in attack is equally flawless.
When developing software, you do well to apply the same principal — keep it simple. Complex problems can be broken down into simple building blocks. If you find that you have code that is difficult to understand or resistant to change, that’s often a good indicator that you are approaching things in the wrong way and need to take a step back. Once you have your design based on simplicity, execute on it relentlessly. Don’t take short cuts hoping that a particular situation will never arise, write your unit tests to cover as many scenarios as possible, cater for scale and performance.
Or as Netflix has it (with thanks to Anup ☁ Jadhav for the tweet):
Both teams today had world class players, and by that I don’t mean the best in the world, but top 5–10 in the world. Some of these players are the best in the world, and New Zealand had more of those than the Lions. But all of these world-class, professional athletes at the pinnacle of their careers are focused on one thing — their team winning. They aren’t looking to make themselves look good at the expense of others, instead you’ll see the likes of Sean O’Brien running the length of the pitch to support a couple of the fastest players on his team, both of whom are about half his size. The fact that he ended up scoring a try would have been the last thing on his mind, all he cared about was getting there to provide support to his team-mates. That’s what your brilliant developers should be doing — supporting the rest of the team and helping everyone else to bring their A-game. They can still dazzle everyone with their individual ability, but not at the expense of the team or the project.
Accepting mistakes happen
After the hour mark, mistakes started to creep into the Lions game — passes going behind the man, the ball being dropped or knocked-on under pressure, holding on too long when the support was slow to arrive. Watch the rest of the team when this happens, they have a brief commiseration with the offender, then give them a pat on the back and tell them to forget about it. Nobody gets thrown under the bus, there’s no culture of blame in the post-match interviews, as a team they collectively succeed or fail. The same applies to software development. People make mistakes. If a mistake gets into production and causes a major issue, that is typically a team failure rather than an individual, as the code should be reviewed, QA’d UAT’d before making it into production. If changes aren’t going through full testing before going live, that’s a failure of the process not the individual developer. If you have a culture of blame, your developers will (a) become nervous of doing any work, lest it end in recrimination and (b) try to cover up mistakes rather than admitting to them early on which allows them to be fixed with the least effort.
In the first half New Zealand tried to sack the ball carrier in the rolling maul, and conceded a penalty. Rather than continuing with that approach, they realised it wasn’t going to work and changed tactics. This is something that a lot of teams struggle to do with the emphasis on a pre-determined game plan nowadays. The England world cup winning team of 2003 were also very good at this, but in my opinion mainly because captain Martin Johnson would quickly see that something needed to change and would take the responsibility to make it happen. The same applies to your development processes — if your developers are struggling with part of the process, or complaining that it is getting in the way and slowing them down, look at changing it. If they are coming up with the solution, then even better — they are thinking about how things can be improved for a better outcome, so listen to them rather than saying this is what we are doing because someone up the food chain dictates it.
The All Blacks have been dominant for a long while now, and it always feels like the rest of the world is playing catch up. But they never get there because while everyone else is figuring out how to beat them, they’ve moved on. They don’t sit on their laurels believing that what they have done will be more than enough for the foreseeable future, they’ll challenge every part of their setup to see if it can be improved. The same applies to software development — if you stick with the way that you’ve always done things, you’ll get overtaken by others that are finding better ways. The good news is that it’s never been easier to keep up to date with best practice in the industry, while the bad news is you have to expend a lot of effort due to the sheer volume of blogs, tutorials, open source examples etc.
I’m better known in the Salesforce community as Bob Buzzard — Umpteen Certifications, including Technical Architect, 5 x MVP and CTO of BrightGen, a Platinum Cloud Alliance Partner in the United Kingdom who are hiring (brilliant jerks need not apply).
Brightgen Careers | Brightgen
For 10 years organisations have relied on BrightGen to show them what Salesforce — and their business — is capable of…
You can find my (usually) more technical thoughts at the Bob Buzzard Blog