Building Satisfactory Architecture
It’s all Scrum and (Video) Games, Part 2
In my last article, we discussed the general concepts of gamification, and how you can play Overcooked to learn about concepts like cross-functionality and complex environments.
In this article, we’re going to build a Megafactory, complete Project Assembly, and learn about technical debt!
Satisfactory is a game in which you start on an alien planet with nothing but a scifi pickaxe and a construction hub, and aspire to build the factory to end all factories.
If you’ve ever loved to build with legos, but were a bit miffed that the legos never *did* anything, or if you like model trains and would like one that spans an entire planet, this is the game for you. More importantly, it’s a great tool to teach people about how complex systems accrue technical debt, and how to prevent turning your hot new tech of today into monstrous sanity-devouring legacy systems of tomorrow.
In case you don’t know, legacy systems have a bit of a reputation with developers.
I’d argue that even for Masters, it’s still a huge PITA to go through years-old code that was built to house a monster birthed by some poor cursed project manager, trying to find a bug that has hidden itself in the farthest corner.
So how does Satisfactory come in?
Easy enough, because it starts like this:
Do you see the green field and the wonderfully simplistic architecture?
Look, there is a power plant [compute], and it connects to a mining rig [Data entry] which we stand on (1), a smelter [backend system](2), a processor [data analysis tool] (3) and finally, there’s a storage system [data storage] (4).
[I put roughly equivalent IT systems in square brackets to drive the metaphor home with a sledgehammer.]
But soon, you need more than that. Maybe you need a new feature that needs additional data storage, and some more computing power. Maybe a shiny new UI that requires you to connect to several other data points as well.
But now your customers are running amok on your platform and finding out things no one should see and you need some security patches and redundancy plans and everything has to happen FAST and then there’s new features and new bugs on those features and new patches and 6–8 sprints later, you arrive at…
Imagine I asked you where the power comes from in this factory, and where the finished goods are stored. Also, please tell me what that green thing at the bottom is doing and where we source our copper.
Imagine that first power station you built breaks and causes a cascade failure and everything stands still and your product owner demands you fix it NOW, but you just can’t. The website remains down for days, and it costs your business hundreds of thousands of dollars. This concept is also called technical debt, because you accrue it in the process of building things fast, and if you don’t pay it down regularly, it can bankrupt you just as much as normal debt can.
The cool thing about Satisfactory is that it’s a multiplayer game, and that you can access and interact with other people’s factories. (Up to 4 players sharing a server is officially supported, more are possible). And while every player needs a relatively strong PC, this interactivity allows for some really interesting training scenarios.
Here are the bare bones of a scenario I came up with. This is by far not the only way to use the game to teach. Feel free to modify this approach as you wish, e.g. by adding mini retros after each score.
- Have two teams build a factory to produce X amount of an agreed-on product Y. You can do small amounts by hand, but in larger quantities the best way to do this is by automating stuff, so make sure the volume is big enough.
Whichever team finishes first wins 1pt. - Then have both teams stop production and empty their holds/containers. Then have them log off and break something in their factories. Destroy a crucial power cable, turn off a machine, bulldoze a conveyor belt, whatever you like, but don’t make it too obvious. Have them build another batch X of product Y.
First team wins 1 pts. - Tell the teams they will now need to produce Z amount of a product Y+, which requires Y. (For example if Y is processors, Y+ could be computers)
Have both teams stop production and empty their containers again. Break whatever you like… - …and have the teams switch factories. (Cackling maniacally at their expressions makes you win this game forever.)
- The first team to produce Z of product Y+ wins 2 pts, but the team who built that factory originally also wins 1 pt.
In case the people you are playing with don’t get it, the metaphor really isn’t that hard to spot. Building systems that are well documented and instantly clear to whoever looks at them is not only nice, it can be crucial for your survival as a company. Technical debt is a slow and insidious killer.
Yes, clean architecture and coding may take more time, and yes, writing clean code in complex environments requires thinking ahead to anticipate things you can not possibly know about in advance. But which (code) factory would you rather work on? The Babylonian death trap above, or something like this:
In this picture, things are much clearer. At one glance, you can see all the constructors at the bottom use copper pipes to manufacture goods, for example. Everything to the right uses sheets of iron, and the machinery at the bottom right uses iron rods. If I asked you where your iron comes from, you only had to look for a minute until you found the source.
The same goes for your code. Good architecture is obvious and allows future coders to understand its’ logic in a short period of time. When something breaks in a well-written system, you are able to react quickly, because you can follow back the route of the error to its’ source.
So build a wonderful factory that people will love. Build great code.
Thanks for reading, I hope you enjoyed this episode of Scrum and Games and will swing by next time when we will be killing dragons, liches, mind-eaters and other evil stuff.
Do you want to write for Serious Scrum or seriously discuss Scrum?
