Tooth and Tail is simple. It has to be simple because the game designers had a very challenging goal: Make a Real Time Strategy game that is reasonably playable on a console. Real-Time Strategy games are notorious for needing high-speed and complex inputs (professional Starcraft players’ fingers perform over 400 actions per minute) that are simply not possible with the constraints of a console controller (even with all of the buttons they’ve added after Nintendo produced the perfect game controller in 1990). But the designers were smart, and they looked realistically at the constraints of the system, and they crafted the game to fit those constraints. The result is a playable, enjoyable game about a Soviet-revolution inspired rodent uprising on a farm. The designers of in-house corporate programs and databases need to learn to be realistic about the actual uses of their programs.
I. Lesson in Project Design: Accept the Probabilities of Disaster so you can Plan for Prevention; Don’t Plan for Immortality and Invulnerability. (#dontbeateen)
In the digital age, there is an increased focus on preventing and eliminating problems/errors. The promised outcomes of flawless perfection are enticing, but the realities of inevitable problems require more effort be put into managing problems and recovering from disasters.
Computers amplify the speed and scale of what people can do. This makes it easier for people to do more, and to do more, faster. This includes making mistakes bigger. Years after a British woman got 15 minutes of fame for accidentally ordering 500kg of chicken wings, Samsung accidentally made a $105 billion ghost.
Samsung Securities Co (a financial services company owned by conglomerate Samsung Group) tried to pay a dividend to their employees, but accidentally gave the employees shares instead. The 1,000 WON dividend became a 1,000 SHARE distribution- creating over $100 billion in new shares. Then some employees immediately sold those shares. There were a lot of safety measures that failed in this story. The program should have been able to calculate that this order totaled over 1 trillion WON, more than 30 times the entire company value. A second human should have checked over the work for simple, obvious errors when there is a potential for this level of damage (anything at a company-wide level for a publicly-traded international corporation would certainly qualify). Several departments should have reviewed the work (compliance, risk, accounting, finance, legal—almost anyone!). Samsung’s own internal compliance should have also prevented the sale of the ghost shares.
II. A Lesson in Categorical (Or Macro) Errors: Some Mistakes are Annoying, Others Are Fatal. Design to Catch and Prevent, Not Headline and Damage Control. (#dontbeaceleb)
Mistakes happen a lot when computers are involved. Sometimes it’s the user, sometimes it’s a problem in the code. But when a user catches a problem, they can assess the problem in a broader context, and determine just how bad a mistake is. A bigger mistake is just more obvious to a human than a computer.
Many years ago, a friend of mine got on a flight and found someone else sitting in his designated seat. Not wanting to cause trouble, he simply took the empty seat next to his designated one and prepared for the flight. As the crew prepared for taxi and takeoff, a flight attendant welcomed passengers to their non-stop service to their destination city. Upon hearing this announcement, the woman next to my friend hurriedly gathered her belongings and fled the plane.
She wasn’t in the wrong seat. She was on the wrong plane.
Computer programs don’t intuitively differentiate between the severity of errors: the wrong plane and the wrong seat are just two errors if you’ve never flown and don’t know have a broad concept of travel or the context of moving around a world. To a computer, being in the right seat is still pretty good, just like executing a financial order with the correct number is pretty good – even if the number is in the wrong field or tied to the wrong variable. What humans easily grasp, computers are often unlikely to infer. The right detail at a micro-level cannot remedy a catastrophic error at a macro-level.
User errors are inevitable. Programming errors are likely. The more we rely on computers, programs, and apps for the things that allow our lives to function, the more likely it is that our lives will be disrupted by programmer or user errors.
III. The Solution: Make The Programs Flexible, and Make Problems Fixable.
Tooth and Tail’s success is rooted in the realism of its game designers, who sacrificed dreams of a more complex game (that would have been unplayable) for the right game that fit the actual constraints and experience of the player. Designing with the actual user’s experience in mind—with special consideration for what can go wrong—is more important for project designers and programmers every day.
There is an increasing drive to try to use computers to prevent any errors, mistakes, or problems. However, these solutions only make problems worse because they decrease flexibility in and around the program. The solutions is to move in the opposite direction: programs need to play less of a role in trying to self-regulate and self-repair, while users and programmers take a larger role in guiding and overseeing the programs.
But wouldn’t this much red-tape bureaucracy be time-consuming? Wouldn’t it be inefficient to invest so much effort in a simple dividend payment? It would take time and resources, yes—but efficiency measurement is relative to scope (among other factors): it certainly appears inefficient if 6 people spend 10 minutes each to look at the same work and find no error. Here, we would conclude that a full hour of productivity was wasted. However, if 6 people took 10 minutes each and found a problem that would have cost 1,000 hours of productivity had it not been discovered, we conclude that we have a net gain of 999 hours of productivity.
Although problems like these cannot be entirely prevented or eliminated, they can be contained and managed. If a person is on the wrong plane, they can quickly determine the outcome of their choice and work on a solution. People will still get in the wrong city from time to time, but they don’t have to end up in the wrong city as a result. Similarly, employees will make occasional typos or errors in their accounting and payroll from time to time, but that doesn’t mean that financial markets have to be rocked as a result.