How Mark Summers helped our office become better friends while fighting aardvarks for charity

A few times each year, our office holds a hackathon (cleverly titled HACK’D) and we’re able to work on whatever we want for two days. Last HACK’D someone had organized a scavenger hunt around the office which went over really well. Rather than work on a new app, I wanted to take the concept of a company-wide game further.

Our team of four was fresh off an online game called Neptune’s Pride and I was interested in seeing if we could incorporate some of the elements of the game to the whole office. Here are some of those elements:

  • Takes a month to play
  • Lots of players
  • You get to know your coworkers more deeply
  • You end up hating your coworkers

We brainstormed ideas on how we could take an existing competitive game like Neptune’s Pride or Diplomacy and rework it using our office as the map. We knew we wanted everyone in the office a part of the game by default, whether they liked it or not. One of the team members had an idea: make it a cooperative game rather than having people or teams compete against each other. This not only sounded more fun but solved that pesky “hating your coworkers” problem.

Having decided on creating a cooperative game, we sketched out our main goals:

Get people from different departments to know each other
While most people in the company knew each others’ names, the tendency exists to mainly talk to people you either work on projects with, play a sport with, or those who joined the company around the same time. There are lots of people working here who don’t fit into any of these categories but you might still get along with. Even worse, there are some entire departments that are so physically far from the bulk of the team that interaction is minimal. As a result, members of far away teams can become a mysterious unknown island.

Experiment with an office wide game
This was the goal that resonated with me the most. I love games and have fun creating things, so I was excited to see what we can learn from this experiment and how far we could push it. Could this game be something that we do more than once? Does this have bigger potential than just being played at our company?

Liven the office up
I’ve heard more than once that our office is very quiet, which seems to clash with the aesthetically fun environment here. Tech types aren’t known for being particularly outgoing, but while introverts abound I don’t believe that the people here want to be left alone. Many want to be involved, talk to more people, and have more fun at work but just need that little push. Hopefully this game could be that push while also giving the office a warmer, higher energy feel.

An early obstacle was figuring out how to encourage our officemates into the game. The aforementioned scavenger hunt was prize-based, but since this would be a co-op game it would be pretty difficult to get good prizes for 100 people based on our $500 budget. We realized that having the prize be a donation to charity would work because it will motivate some while guilting others into action. Hey, whatever works.

To give a sense of pulling the office together, our game would revolve around being attacked from outside forces. A game needs a name, and thankfully some of my more over the top names were vetoed (“They’ll Kill Us All”) in favor of “We’re Under Attack!” which satisfied everyone. The game would involve multiple attacks per day for about a week and our coworkers would need to gather in the assaulted section of the office to “defend” it.

I usually try to crowbar in create a comedic video for any project I’m working on and our team devoted a work day to filming a video introducing the concept and tone of the game:

Yup. We got Marc Summers of Double Dare fame to send us a video clip promoting our game. Don’t ask me how it happened, we just wanted it enough and somehow got it. How could our coworkers who mostly grew up in the 80s and 90s resist a game that involves Marc Summers?

The core loop of our game was to have MeetMe employees gather into different zones of the office that were themed and mapped out:

Gameplay map that mirrors our office.
Gameplay map that mirrors our office.

Each time our office successfully defended an attack, we donated $50 to a local Boys & Girls Club. To defend an area, there needed to be a certain count of bodies there. To make things more interesting and also to learn more about each other, we sometimes required people from certain departments and other times made people worth more if they had certain attributes. For instance our first attack was in the QA area. Here is the email that went out:

first-emailDid you put together that BUGS were attacking the QA testers, whose jobs it is to find and eliminate bugs? So clever.

We had no idea how many people would show up. Some on our team argued that we should require less people so that we didn’t start off with a loss. A measly three people could have came and it wouldn’t have surprised us. Do we have a moral imperative to try to get these missions to pass, for the sake of the charity? No, we decided. The game must have integrity, else why bother playing it? As it so happens there were 17 present for the first attack so I threw together a comically bad photoshop showing the participants and the defeated bugs.

1-bug-attack

The photoshops ended up being a really fun thing to do. It gave character to a game that could have ended up being very generic (“Meet here, take a picture in silence, go back to your desk”). I got advice to play some music while people were gathering because it can be awkward while people are milling about in wait. The attackers started to get more and more ridiculous as well, such as the Aristocratic Aardvarks:

aristocratic-aardvardks

We also started adding more of the bonus qualifiers and we would ask people about them. In one of the challenges a Giant Meteor was going to hit an area of the building. Anyone who had been to space camp counted as 10 people. While asking people about their bonuses, we found out that one of our coworker’s father is an actual astronaut. We found out all sorts of things about each other, such as who owns a horse, who has been to an Aerosmith concert (and is willing to admit it), and who cried in the Never Ending Story when Artex sunk into the Swamp of Sadness.

neverending-story

Pretty sure people lied about not crying.

The amount of people showing up to defend each attack grew steadily. No one was forced to participate, it was just good old fashioned peer pressure. You didn’t want to be the one NOT in the picture of a Sharknado attacking office. Unsurprisingly, the more fun and whimsical we made things the greater the participation was. Our team had spent so much time on the technical aspects before the start, such as debating the best notification system and working on an accurate map of the office, that we initially overlooked the fun factor.

We had two attacks per day over the course of 5 days. As the game neared the end, I thought the game was going a little *too* well. Is this not challenging enough? Being the most sadistic member of the team, I wanted to really stretch these people. They had to earn it! Our final challenge was the most epic yet – The Nothing from the Never Ending Story was threatening our office’s very existence.

It would take 100 people to defend this greatest of foes, a tricky feat considering there are only maybe 90 people working here on a good day. Our group of course had to rely on the bonuses, which included things like acting in a movie, publishing a novel, and of course crying when Artex sank. Not only did the team reach the 100 total, they blew it away. I was surprised at how much so many of our team has accomplished in their lives. Besides being nice getting to know your coworkers more deeply, it’s pretty inspiring to see what kind of people we have working here. 10 out of 10 attacks successfully defended, all $500 went to the charity.

10-neverending-story

We sent out a survey after it was all said and done to see what people liked and didn’t like. Beforehand we were very worried about interrupting people’s work (we were after all gathering 50 people around a random person’s desk while blasting “The Final Countdown” on my laptop). 23% of respondents were “a little annoyed” and everyone else wasn’t annoyed at all (with no one selecting “very annoyed”). Almost everyone enjoyed taking the pictures and receiving the emails describing the attacks in all their horribly photoshopped glory.

Sadly, only about half the people found that they learned useful things about their coworkers that they would be able to use to start a conversation. If we do another game like this we will have to come up with different mechanics to get people to know each other better.

I was curious if people were participating because it was fun or because we were donating to charity. To my chagrin, only 13% said they would have participated even without the charity, while 30% said they would not have participated without the charity. The majority, 57%, said that the charity motivated them some. I like to believe that most of that 57% would have played along anyway.

Most of the respondents (63%) said they’d like to play “We’re Under Attack!” quarterly, with the rest split between monthly and yearly. This does seem like the kind of game that you need a break from for a while before you start to miss it. In that sense, it is very similar to Neptune’s Pride and Diplomacy. When you’re in it, it consumes most of your attention. When you finish it, you definitely want some space.

My biggest takeaway from the experience is a new appreciation for playtesting and the iterative process. We also learned what are the most important things to focus our time on and which aspects people didn’t even notice. I would venture to guess that my team’s experimenting with live social games isn’t over and hopefully we can come up with a game that is effective at making a workplace more fun and social while also being something that any other office could implement.

Now if I could just get Marc Summers on board for the next one…

A look at Apple’s new programming language: Swift

There has been a lot of buzz over Apple’s new programming language, Swift, and many questions as well. Why did Apple need a new language? How is it different from Objective-C? As a developer, should I learn Swift? We’ll dive into these topics in this post.

A Brief History

Swift is the heir to Objective-C, so it’s very difficult to talk about Swift without first talking in detail about Objective-C. Objective-C was created in the early 1980s and descended from both C and the Smalltalk Language.

While most every programmer is familiar with C, Smaltalk is more obscure. It’s an object-oriented language and uses a message-passing style to call methods. (This will come into play later when we discuss Swift syntax.)

During his exile from Apple, Steve Jobs formed a company called NeXT. This company licensed Objective-C in 1988, and they used the language to build an operating system called NextStep. Flash forward to 1996, Apple’s in bit of a rut and they’re looking to update their operating system…Apple acquires NeXT and uses it as the basis of Mac OS X.

Things were fine for a few years and a small amount of developers quietly made Mac desktop applications. In 2007, everything changed when the iPhone was released. Developers were soon able to release third party apps in the App Store which led to an explosion of interest in Objective-C.

What’s wrong with Objective-C?

So what’s the problem? Why can’t we just use Objective-C until the end of time?
In short, Objective-C was never intended to be as popular as it became. It was used for the OS and Mac apps, but there wasn’t a mobile app industry at the time and no one could anticipate what a game changer the iPhone would be.

Objective-C has a somewhat tough barrier to entry because it doesn’t look like a lot of the languages that descended from C like C++, Java or C#. As far as aesthetics go, Objective-C is fairly hideous.

Here’s a sample of Objective-C code:

For comparison, this is how you could accomplish the same thing in Java:

Objective-C can be intimidating to programmers who aren’t used to this syntax. Let’s take a look at some of the issues here.

  • We have square brackets all over there place
  • An asterisk before the variable name
  • @ symbols
  • Lots of extra words cluttering up like alloc and initWithFormat
  • What’s with this “NS” and why is that cluttering up the String?

You’ll see this “NS” in many classes in Objective-C: NSArray, NSString, NSDictionary, etc. It’s a nightmare for autocomplete.

Because Objective-C doesn’t have a concept of namespaces, class names have to be unique, so you need to add a prefix like “NS”. If we were to create a custom string in the MeetMe app, it might have a name like MMString.

The prefix “NS” is a relic from when Objective-C and its Foundation framework were built using NextStep. Again, this was created way before anyone could anticipate how popular it would be to code in the language. If they had a crystal ball and saw the future, there’s a good chance the team at NeXT would have made the entire language easier to use.

Over the years, Objective-C has gotten friendlier with more features you’d expect out of a programming language (like blocks and literals), but Apple was looking for a lighter language with less barrier to entry and to clean up some of the relics of the past — Swift is their answer.

Concise

One of the main benefits of Swift is that it is a much more concise language than Objective-C. Gone are:

  • Semicolons ;
  • [Square brackets ]
  • #import statements for classes
  • Alloc/init, lengthy method names

Back to the previous code samples with the strings — here is the same line in Swift, and you can see it has done away with all the weirdness we pointed out in the previous example, looking a lot more like a modern language:

You can also overload the arithmetic operators with your own custom functionality. In Objective-C, there is no overloading; you have to create a new method name if you want to have different types of parameters for the same method. As you may know, autocomplete gets pretty cluttered with all these extra methods.

In Objective-C you need to access properties with the “self” keyword and also call methods on self. In Swift, the self is implied in properties; you can write it out if you want to be explicit, but you can omit self for conciseness. If you call a function without specifying a variable to call it on, the function is implied to call on self so you don’t need to declare that either.

Objective-C:

Swift:

This is an example they used in the Apple Keynote when they first introduced Swift.

Here, you see some code you’d commonly see in an Objective-C app where you spend a lot of time checking if the delegate is nil and checking if the delegate has a particular method before you call it.

In Swift, they’ve cut down on a lot of typing with Optionals:

The use of Optionals is indicated by the question marks. (Optionals will come up later when I discuss safety.)

Another change that results in more concise code is the use of strict types in collections.

Here is a sample method from Objective-C:

You pass in an array of donuts, but the compiler doesn’t know that the array only contains NSDonuts. We know it because of clues from the method name (and maybe the documentation) but, for all the compiler knows, there could be strings in that donut array.

So, we create a donut variable and cast it as NSDonut to assure the compiler that it’s ok to call eatDonutMethod on it. Is there a better way? Here’s how this same method could be implemented in Swift:

The syntax is a little flipped, but we have the same name of the array — donuts. Instead of a general array type, this has an array strictly of donuts. This allows us to call donut methods on any object in the array without needing to cast it because it has to be a donut; the code won’t compile if you try to send an array of strings to this method.

It’s a great win for more concise code, but this also demonstrates another feature of Swift — its emphasis on safety!

Safety

All variables are statically typed in Swift, meaning you have to declare if a variable is an Int or a String; for example, you can’t just say it’s a variable and call any method you want on it later.

While Objective-C is also statically typed, it uses the generic id property in collections as we previously discussed. This sometimes leads to errors happening at runtime when a collection ends up having a type that you weren’t expecting. In Swift, because collections are of a particular type, there will be an error before you compile rather than at runtime if you do pass in the wrong type.

Type can also be inferred; as you see in this example, you don’t need to explicitly declare the variable type.

Here, it is inferred that donutArray is an array of donuts based on the assignment. Under the hood, this is still statically typed; donutArray is an array of Donuts, even though you didn’t have to explicitly type it out like the line above. You get the safety of static typing, but it’s also concise.

In Swift, variables are only able to be changed if you declare them a var. The preferred practice is to declare your variables as constants using the ‘let’ keyword. Not only does it optimize the code and make it faster, it adds safety by throwing you a warning if you try to change the contents.

Swift really tries to get you to think about how you’re going to use each variable, which we also see with Optionals. Nil or null pointers cause a lot of problems in programming, and different languages have different ways of dealing with it. In a lot of languages, your program will crash if you try to call a method on a null object.

Because Objective-C was inspired by the SmallTalk language, it uses message passing to invoke methods (told you we would come back to that!). A feature of message passing is that you can get away with calling a method on a variable that doesn’t have the method and the compiler won’t complain. In Objective-C, messaging nil returns nil, so no harm, no foul, no crash.

And yet, this isn’t ideal. What if you need the return value from this method and getting back nil will crash your program? You could wrap this in a nil check, or use the respondsToSelector method, and that is what we have to do all the time in Objective-C. Swift is looking for a better way to handle the nil problem.

Enter Optionals. Here’s an example from earlier — let’s say later on you want to clear out the donuts and set the variable to nil:

You cannot do this because then donutArray would no longer be an array of donuts. A var expects a value at all points of its life cycle, from initialization until it is deallocated. How you can accomplish this is by making donutArray an Optional:

An Optional behaves like how variables in Objective-C behave in that they can be nil at any time. They also do not need to be initialized to a value.

Optionals should be used only when necessary because they work around the safety Swift has created to try to eliminate runtime errors that crop up around surprise nil variables. The preferred order to create variables is:

  1. let constant
  2. var if it needs to change
  3. optional var if it needs to be nil at some point

Optionals are generally meant to be used with a question mark, meaning that there may be an object there or it may be nil. Sometimes you need to guarantee that there’s a value there. The easiest was to use the underlying value of an option (and least safe) is to to force unwrap it by using an exclamation point.

This is a brute force way of saying, “Just trust me, there’s a value there.” This should be avoided unless absolutely necessary because it goes around the safety of optionals and the program will crash if it turns out you were wrong and there’s no object there.

The preferred way to handle this is using a new statement, “if let” (also known as Optional Binding). This creates a new local constant equal to your optional only if there’s a value there. You then safely use the new constant inside the block.

Optional binding is similar to a nil check, so that seems to go against Swift’s push for concise code. I think that, as Swift develops, the syntax for this situation will become more concise. For now, this is the way to safely handle optionals when you need to guarantee they’re non-nil.

Other Safety Features

Swift has eliminated several features that allowed programmers to be a little lazy at the expense of safety. Here are two conditional statements in Objective-C that both do the same thing:

If you only have one line inside the body of an if statement, you have the option of omitting the curly braces in Objective-C. The problem is that it’s really easy to think that you’re just going to need one line, then come back to your code sometime later and add more lines not realizing that you also needed to add braces. Those extra lines will not be tested by the conditional statement; they will always execute!

This is an insidious error because the compiler will not complain; it just always executes the extra code. You may not even know there’s a problem until months or years later when unusual things happen. The most infamous recent example of this is Apple’s “goto fail” SSL bug, which happened while using this same shortcut:

Apple decided that this convenience was just not worth the risk, so the brace-less conditional checking in Swift is disallowed. Another area Apple made safer while actually letting us be lazier is in switch statements. Here is an example switch statement in Swift:

Notice there are no “break” statements anywhere. They are no longer an option in Swift — every case breaks automatically. While this takes away some of the flexibility of being able to fall through to the next case, it eliminates the common problem of forgetting to type “break” after every case and accidentally falling through when you didn’t intend to.

Instead of falling through to additional cases, Swift allows adding several options to the same case (see the “left”, “right” case). And, thankfully, you can now use non-number types inside switch statements such as strings (as you see in the above example), classes, and optionals.

Finally, switch statements must now be exhaustive, which usually means that a default statement is required. In the case of an enum you can usually evaluate all cases; however, there is no way you can evaluate every possible string combination, so use default if you don’t want to get a compiler error!

There are lots of other examples of safety in Swift, too many to go through in this post. The main takeaway is that Swift was designed to be easier to learn, faster to run, and safer to code in than Objective-C. It is evolving and has had some significant changes in its short lifetime. It remains to be seen how quickly Swift will supplant Objective-C, but there seems to be justified enthusiasm for non-Objective-C programmers looking to get into iOS app development.