After watching competitive StarCraft 2 last night, I kind of feel like writing a post on how playing a game can work wonders for your agile mindset.
Oftentimes, when I learn, I don’t remember things ‘in their context’; for example, I don’t read IT related books. They just don’t stick. I do remember ‘similar’ things. Things that are more or less the same but in a completely different context. My wife explains it where my mind is basically working like one of those crazy detective walls, with the pictures and the strings. With the weird exception that pictures with no strings just get…well..‘garbage collected’. Really…really fast.
She's not wrong, you know
This in mind, I love learning my IT lessons from someplace else. History, Literature, Philosophy, Working Out, or even something as seemingly time wasting as gaming.
A brief summary of a most complicated game
StarCraft (2) is game that’s well over 11 years old already. It’s, what one would call, a ‘a real time strategy’ game. You gather resources, build a base, build an army, and destroy your opponent whilst he is trying to do the same to you.
Think like chess, except, you move at the same time. And you can build new pieces. If you took care of setting up a proper economy first. That’s what’s called ‘macro’. Making sure you have a proper economy, a well defended base, etc.
Of course, what’s different from a ‘traditional’ game like chess, is that there’s also, micro. Which is basically the art of controlling your, sometimes individual army units. Units in your army have various abilities. Some can cast devastating spells, others can hit themselves with some performance enhancing drugs. Tanks can drive, but they can also transform into a static, long range artillery battery. And when it comes to micro, things like when to activate your specific ability, or how much, or where are actually crucial.
So while a good macro can set you up for victory, if you mess up the micro, a smaller army can still beat you.
To sum it up, StarCraft 2 is a very hard game. A year or two ago Google Deepmind AI teams did an interesting project in creating an AI for StarCraft called AlphaStar. The results are open for interpretation and I won’t bother too much with them here. Let’s just say creating a self learning AI for SC2 was / is a huge challenge even for those best at those kind of things.
Today’s lesson
So for me, when I talk about, and play StarCraft, there is a lot to learn. It’s a complicated fusion of strategy - what army composition to pick, to tactical - when and where to attack or defend to operational - controlling the army as it goes on.
For today, I want to focus on that last bit; operational skills, and the mindset needed to grow in this area. For other lessons, well, perhaps some day, other blog posts.
In playing StarCraft, there is a dichotomy always at work, where you need to balance “doing your own thing” versus “react to what’s happen¨. You need to do both. But you can also overdo either one.
For example, if you only react to what your opponent is doing, you’ll find yourself oftentimes going on a wild goose chase constantly trying to adapt. ‘Now he’s building X so I need to build Y. He’s going here so I need to go there’. This translates to what could happen in software development right? We want to have some sort of shield between the team, and all the influences from outsides stakeholders or users, lest they’re just busy all the time with interruptions and never get to any of the planned backlog or roadmap.
On the other hand, you can’t just “not react”. If the data center is in flames, you can’t just say “Put it on the backlog and we’ll deal with it next iteration”.
This is the same in StarCraft. You need to do your own stuff, do your own ‘build’.
You go through iterations too:
10 you build some workers for the economy
20 do some scouting
30 you build some units for your army.
40 repeat do some research for new units or upgrade
50 goto 10
But if you’re opponent is airlifting some buggies with flamers on top to lay waste to your economy just as you are scouting, simply doing step 3 and 4 before dealing with it will end up going very poorly.
Light em up! - 3 flaming blue buggies making a bbq of an alien mineral gathering line
In StarCraft, reacting too late to above mentioned interruption will ensure you’ll be stuck in the ‘Metal Leagues’. The competitive league system in StarCraft starts with bronze, going up to silver, gold, platinum, diamond, masters and grandmaster leagues.
So ‘The metal leagues’ are roughly the lower 50% of the player base that play competitively. Do you want to get stuck on the bottom half of all DevOps teams? I think not. Time to step up our game.
Let’s go pro
Now that we have one example of similar things going wrong in both StarCraft 2 and software engineering, let’s see how StarCraft 2 pro’s handle this, and what we can learn from it!
When analyzing ‘top-tier’ players, you can see their handling of interruptions could be easily summed up as ‘Stay calm, just react and deal with’, but that really comes down is some key aspects that we can learn from.
1. Know the risks
If I’m playing StarCraft, as race ‘A’ vs an opponent of race ‘B’ on map ‘C’, he could hit me with a likely attack consisting of ‘X’ and ‘Y’ at about 4 minutes. Or to put it more concretely, if I’m playing as a Zerg against a Terran, I know I could expect the first hellions (fire buggies) to arrive at my base by about 4 minutes from the start of the game (There’s a timer in StarCraft’s UI, thankfully).
Yes, such a list is going to be long, rather dull, and never complete. Like our software world, the StarCraft 2 scene is constantly evolving. Types of times that were popular 2 years ago are only rarely used today. (Funny how that’s another parallel - no set ‘meta’ for what’s the best approach) But still, it’s crucial to know what likely risks you could run into.
So for Software engineering? ‘For the first 4 weeks of my project, I can expect my product owner to realign major backlog items due to prioritization after stakeholder meetings’ I’m not saying that’s true for your project, but then again, you can just imagine things like that, can’t you?
We run risk assessments on our technical software or production systems, but how often do you consider running this assessment on your process? If only in your head?
You can’t overanalyze every situation, but in a game of StarCraft 2, I do try to think:
Given my own plan for this game, what’s the most likely thing that could start me off towards a defeat?
Why not do the same for your project and team processes??
2. Minimal Viable Reactions
So, the shit has hit the fan. There’s a mess everywhere. Cleaning the room will still suffice though. Don’t tactically nuke the building.
In StarCraft, it’s a bit of a trap (or from an opposing side, a strategy) to overreact. I go for a few flying units, making my opponent think that’s my likely strategy. He overreacts by building too much air defense, and my ground army rolls him up.
Looking back on your past experiences, don’t just remember all the times something came up that looked really big. Everybody was in a buzz and going hard, only to find out later it wasn’t really that big a deal?
Something happens to my economy in a game? I make the minimal number of units to defend. My opponent is giving of a sign that would require me to overhaul my strategy - the architecture of my army? I double check, nay, I triple or quadruple check before giving up on my original plan.
This is an attitude we should practice too in software engineering. If there’s a new feature suddenly being demanded; are we really critical enough of the minimal required implementation to satisfy the stakeholder?
If there’s a security audit threatening to ruin or design or architecture, are we double and triple checking if we actually need adjust the plan as dramatically as it seems at first?
If our boss asks us to do something we don’t feel comfortable with, are we taking the time to double check his intensions to see if we read it correctly? Or are we making our own assumptions like the opponent building too much air defenses?
React to an event with the smallest deviation from your original intent. If the possible resulting deviation from the intent is large, check (again and again) if the event is not a false positive
I’m not saying never change your plans. I am saying, don’t change your intent too quickly.
3. Don’t think, do
So, what happens when that enemy harassing force does manage to find a way into a base. As a player I am notified by the computer that ‘my workers are under attack’, followed by a red blip on a minimap.
I press 4 on my keyboard, which is the shortcut a group of units I keep prepared for defense. I press t which is the attack move command - to tell that army to go where I’m about to click, and attack any enemies along the way there and at that location. Then I click on the red alert on my minimap. So, even before I moved my main camera to the threat, I have units underway to intercept the threat.
Admittedly, that is what I try to do, and that is how players better then me do it. I fail often which is fine; there’s a reason I’m a software architect and not a pro-gamer.
But how does that translate to software engineering? You get an alert from your monitoring? And then? Do you know what to do? Is it a generic alert? Do you need to investigate first? Or have you set it up specifically enough to initiate a specific procedure?
Operational excellence is about focussing on developing reflex like responses to events. For a DevOps team, this means knowledge management. Standard Operating Procedures that everybody in the team knows, practices, and can find with their eyes closed. Not too many, but certainly not too few (and in my opinion, it’s better to err on the side of ‘too many’ procedures rather then ‘too few’)
You establish these procedures not just by your own experience, but also by the experience of others. Like how one can watch replays of other top players in StarCraft, it’s important to seek out similar other Software teams and share ideas and procedures.
In both StarCraft and Software Engineering, if you spend less time thinking on what to do during the moments of chaos, you simply have more time to react to said chaos.
And again, this is not just for technical side. Do you have procedures for how you work as a team? Templates for setting up story items quickly? Maybe onboarding or introduction material for new stakeholders? Automation in place to set up storyboard items them up for automated events? Do you now what to do if the scrum sprint gets interrupted? What if the operations teams gets too much requests and need help?
Wrapping it up
What can we learn from a computer game? I say, about as much as we can learn from anything we really choose to study. We often think Software Engineering is some unique subject field, but I feel that very often the best insights are actually gained by stepping outside of our world and see how other ‘top achievers’ came to be recognized as such.
On the specifics of StarCraft 2; I could write more; and I’m certainly not the first to write about learning from this complicated game and applying it to life or business; There’s a lot of blog posts out there on the analogies between this particular game and business or start-upt strategies. For those of you interested, I’ll suggest this excellent blog post as a good starting point for further reading and learning about awesomeness that is StarCraft 2.
Hope to you again soon! Game on. Or code on. Whatever floats your boat!