This week, I spoke at IteratePHX, a local tech conference, about specific tactics to build a DevOps culture. One of the tactics asking questions along a line of reasoning that I’m calling …. EXTREME Design!!! (Apologies, I might yell EXTREME a couple of more times because, well, it’s fun.)
I still can’t believe that’s not a term that already means something in the tech world, so I’m coining it, Extreme Design™ or XD for short.
What is Extreme Design? It’s designing your software with the notion that, one day, your software will will need to deal with situation that sounds extremely unlikely today.
For example, let’s say you write an iPhone game and a few hundred people are using it (congratulations!). Something happens (e.g. coverage on Reddit, New York Times) and over night your software has a few hundred thousand users. This sounds like an extremely unlikely situation, but I want you to think about what happens to your software in this scenario.
I am not saying you should design your game to handle an extremely large number of hypothetical users. I am asking you to understand what happens to your software should such a thing happen.
Which brings us to the first of three ‘extremes’ we will consider today: large numbers.
In this example, where you have written an iPhone game, perhaps you have some kind of database that stores high scores. If you’re like me, you were probably busy working on game play over spending time making your high score database robust. So now when a flood of users come knocking on your door, the game works fine, but at the end, you can’t record their high score because the database is falling over. My question to you is, did you know this would happen to your database? Do you know what other parts of your game will have issues?
A jump in users from hundreds to hundreds of thousands of users, isn’t he only jump to think about. That is, think about every large number that will cause an issue for your software. If hundreds of thousands will cause an issue, will just tens of thousands? Let’s say you figure out a plan for dealing with these 100K users, what’s the next breaking point? Map out many jumps and have a plan for each breaking point.
Number of users or number of records aren’t the only extremely large numbers to consider. What’s the maximum high score a player can achieve? What’s the maximum latency a user can tolerate before they game stops working? What’s the maximum screen size your layout can handle? I hope you don’t stop at 1080p or even 4K. What’s the maximum storage your game requires? These are all examples of scary constraints; numbers that might be a dead end for your software. However, they don’t have to be so scary. What happens if disk space is 100 times bigger? Would you change the content of your game? What happens if somebody is willing to spend 10 times as much for your game? Would you invest more time in your game? What would make your game worth that price? See? Large numbers can be fun!
The next extreme to think about: small numbers.
Small numbers are not all that different from large numbers, but it will make you think a bit differently. Going to back to your high scores table. There’s a cost for you to maintain this database. Perhaps you only stored the high score because you thought the cost of the database storage is a bit pricey. What if the cost of storing data dropped to only a tenth of what it is today? Would you store additional data about your users game play? What if your users’ latency to your servers dropped to almost nothing? I bet you could build a much more responsive game. What if your users have really low bandwidth? Will they still have fun playing the game? If you rely on a random number, what happens, in the extremely low probability situation, you generate the same number back to back?
The last extreme I’d like you to think about today: Zero. It’s so special, I’m going to capitalize it.
Zero is a super powerful number. I hope you already recognize it as a special and important. Common areas you might have recognized Zero’s unique behavior in software might be dividing by Zero causes problems or that Zero is often the same as “False” in many programming languages. When it comes to EXTREME Design, Zero is just as special. What if your game has Zero Internet connection? Does your game even start? What if you wanted zero bugs? You might need Zero bugs if you’re going to the moon or building a robot to perform surgeries. What would you do differently if you wanted Zero bugs? Does this seem like a ridiculous line of questioning? Maybe, but that brings me to the last major point of Extreme Design.
Do not laugh. Extreme Design depends on your ability to have an open mind and think about hypothetical situations. Feel free to explore. All the relevant extremes may not be apparent on the first pass. Some may seem more realistic or probable than others. Other extremes might be more catastrophic than others. Do not laugh any extreme out the door. Evaluate it fairly, and then, if you determine that it’s irrelevant you can discard it. However, the point is really to make sure you have a complete understanding of how your software behaves in extreme conditions.
Is this everything I have to say on Extreme Design? Nope, it will crop up all the time. It’s a mindset you need to have as somebody who writes software. Now that we have a name for this mindset, I’m hoping it’ll make an extreme home for itself in your mind.
A now, a few bonuses that involve how folks designed around extremes!
This one is a three-parter. Did you ever play Super Mario Bros. on the Nintendo Entertainment System (NES)? There’s a counter for how long you have to complete each level, which starts at 255. 255 is an extreme for an 8-bit system! The NES’s CPU can handle 8-bits at a time, which means 2^8 is 256 and if you start at Zero, means the max number you can easily work with is 255. The implications are fascinating. As a level designer for Super Mario Bros., you need to design each level to be completed in 255 ticks of the counter. Second part of this bonus, the same extreme strikes again in the Legend of Zelda. Link could only carry 255 rupees. Which means the most expensive item Link could purchase must be less than 255. Again, as a game designer, you need to balance how easy it is to collect rupees against this extreme of an 8-bit system. I find his fascinating. Leave a comment if you know what the most expensive item Link could purchase in that game and its price.
I mentioned random numbers and how to deal with the unlikely situation it results in the same number back-to-back. This extreme showed up in Apple iPods, of all things. Music listeners would turn on “shuffle” and expect that they would hear a string of unique songs. Turns out a string of truly random number will have duplicates. Think about rolling a dice. There are only 6 numbers, it’s pretty likely you’ll hit the same number twice. But in a collection of 1000 songs, it seems impossible. But it’s not. Listeners noticed because while “shuffling” you would hear the same song twice. How did they deal with this awful, awful experience of hearing the same song twice? They made the shuffle not truly random! That is, if the random number generator says to play song #569 again, it will skip it and move on to another song.
I used the word EXTREME, in its various forms 27 times.