Coding Horror

I'm a huge fan of the Guitar Hero series. After reading the first reviews in November 2005, I rushed out to get one of the few available copies at my local Best Buy. It was an obscure title at the time-- I had no idea it was even being released until I read the initial reviews, and I'm a fan of the rhythm genre. Guitar Hero is now such a massive success that everyone reading this has probably at least heard of it. It achieved pop culture critical mass, which is the ultimate and final level of success for any video game. It's what every game aspires to, and precious few achieve.

But it was far from a foregone success when it was under development. In fact, Guitar Hero was a highly questionable software development project from a publisher's perspective:

• New, unproven franchises are risky.
• Games that require peripherals to play don't typically sell well.
• Games that cost $70 - $80 don't typically sell well.
• Games with a giant honking box tend to suffer for lack of shelf space.
• The Japanese title "Guitar Freaks", a very similar game, flopped in the US.

Beyond that, the studio behind the game, Harmonix, had a poor track record. Their previous two rhythm games, Frequency and Amplitude, were not exactly hits. Despite great playtester impressions, positive reviews and many design awards, both games sold, in the words of co-founder Alex Rigopulos, "mouse nuts".

This disconnect between creative output and sales took its toll on the team, as Alex explained in a recent interview:

It's torture for the creative team that's making the game, because when you make a game that the reviewers are loving and the playtesters love it and whatnot, you feel like just on a creative level that you've succeeded. But as I mentioned this morning, it's only half the battle, because if you make an experience that can't be effectively marketed, then you're just dramatically capping the number of people who will ever have access to that experience. For us, it was really hard to go through that experience, but we came out of it having learned an important lesson, which is that we needed to think up how to sort of wrap up these experiences in a form that sort of made it easier to reach out to a wider audience of people.

Alex gave a talk at DICE 2007 where he explained the internal debate over Guitar Hero in slide form.

This graph of twelve years of Harmonix' financial results illustrates, as Alex labels it, "The Dream".

It took Harmonix ten full years to finally find success with 2005's Guitar Hero, through dogged persistence pursuing the rhythm game genre.

Harmonix went on to create Guitar Hero II, which greatly amplified the multiplayer and polished the overall experience. After that, there was a schism-- the Guitar Hero franchise, including Guitar Hero III, is in the hands of different developers. Harmonix went on to develop the innovative Rock Band. Instead of the two player bass and lead guitar multiplayer of Guitar Hero, in Rock Band, you have four players-- bass guitar, lead guitar, drums, and vocals.

It's a continuing evolution of the dream:

My biggest hope is that this game deepens people's connection with the rock music that they love. Playing this game changes people's understanding of music. Most people, they listen to rock, they don't even separate the music into the different instrumental components. They don't hear the drums and the bass and the guitar separately, it all sort of blends together into a mash for them. Playing this game changes that. Playing this game changes the way that people hear rhythms. It changes the way they hear the interrelation between different parts. The act of playing it just connects people in a very visceral, physical way with the music that they don't otherwise experience. So really what it's all about for us is just making peoples' connection with the music that they love much more profound. I really do think that on a mass scale millions of people will understand and feel music in a different way because of this game.

I'd like to think a big part of Harmonix' success is -- to steal a phrase from the greatly missed Kathy Sierra -- their dedication not to gameplay, not to code, not to sales, but to helping users kick ass:

Phrase everything in terms of the user's personal experience rather than the product. Keep asking, no matter what, "So, how does this help the user kick ass?" and "How does this help the user do what he really wants to do?" Don't focus on what the user will think about the product, focus everyone around you on what the user will think about himself as a result of interacting with it.

This is how all software should be written: with the user's goals at the forefront.

There's absolutely no better way to experience the sublime feeling of personal success Kathy is describing here than to play Rock Band with your friends and coworkers. If you haven't tried it yet, I envy the experience you're about to have.

Tom Dommett wrote in to share his positive experience with pair programming:

The idea is two developers work on the same machine. Both have keyboard and mouse. At any given time one is driver and the other navigator. The roles switch either every hour, or whenever really. The driver codes, the navigator is reading, checking, spell-checking and sanity testing the code, whilst thinking through problems and where to go next. If the driver hits a problem, there are two people to find a solution, and one of the two usually has a good idea.

Other advantages include the fact that where two people have differing specialities, these skills are transferred. Ad-hoc training occurs as one person shows the other some tricks, nice workarounds, etcetera.

The end result is that both developers are fully aware of the code, how it works, and why it was done that way. Chances are the code is better than one developer working alone, as there was somebody watching. It's less likely to contain bugs and hacks and things that cause maintenance problems later.

In a bigger team, the pairing can change each week so each team member is partnered with somebody different. This is a huge advantage, as it gets developers talking and communicating ideas in the common language of code.

We found this to be as fast as working separately. The code got written quicker and didn't require revisiting. And when it did need to change, more than one person was familiar with the code.

It's an encouraging result. I applaud anything that gets teams to communicate better.

I'm intrigued by the idea of pair programming, but I've never personally lived the pair programming lifestyle. I do, however, enjoy working closely with other developers. Whenever I sit down to work side by side with a fellow developer, I always absorb a few of their tricks and techniques. It's a fast track learning experience for both participants. But I've only done this in small doses. I'm a little wary of spending a full eight hours working this way. I suspect this might be fatiguing in larger doses, unless you're very fortunate in your choice of pairing partner.

I've written about the efficacy of code reviews before. That is something I have personal experience with; I can vouch for the value of code reviews without reservation. I can't help wondering if pair programming is nothing more than code review on steroids. Not that one is a substitute for the other-- you could certainly do both-- but I suspect that many of the benefits of pair programming could be realized through solid peer review practices.

But code reviews aren't a panacea, either, as Marty Fried pointed out:

My experience with code reviews has been a mixed bag. One of the problems seems to be that nobody wants to spend the time to really understand new code that does anything non-trivial, so the feedback is usually very general. But later, when someone is working on the code to either add functionality or fix bugs, they usually have lots of feedback (sometimes involving large hammers), but then it may be too late to be effective; the programmer may not even be around. I think it might be useful to have one anyway, but it's hard to get a fellow progammer to tell his boss that another programmer did a bad job.

The advantage of pair programming is its gripping immediacy: it is impossible to ignore the reviewer when he or she is sitting right next to you. Most people will passively opt out if given the choice. With pair programming, that's not possible. Each half of the pair has to understand the code, right then and there, as it's being written. Pairing may be invasive, but it can also force a level of communication that you'd otherwise never achieve.

On the other hand, peer review scales a heck of a lot better than stacking physical bodies in the same area. Consider the experiences of Macadamian with code review while working on the WINE project:

There were two processes in the WINE project that we weren't used to: public peer reviews, where new code and patches were distributed in a mailing list to everyone involved in the project; and single committer, where the project leader had the final say over which patches were accepted into the source tree.

We soon found out that Alexandre Julliard, who has been the maintainer of WINE and one of the key developers since 1994, was very particular about code going into the source tree. Our team's patches were scrutinized, and when some were rejected, there was a lot of grumbling. "My code works, who does this guy think he is? We're on a deadline here!" But as the project progressed, we realized we were producing our best code ever. Producing clean, well-designed code that was admitted into the source tree at first pass soon became a matter of pride. We also found that, despite the fact that the project was huge and spread worldwide, we knew exactly how the whole project was progressing since we saw every patch on the mailing list. We now conduct code reviews on every project, and on larger projects, we set up an internal mailing list and designate a single committer. It may be painful to set up code review at your company, and there may be some grumbling, but you will see big improvements in the quality and maintainability of your code.

I think both techniques are clearly a net good, although they each have their particular pros and cons. I encourage people who have experience with both pair programming and code reviews to share their experiences in the comments. Is one more effective than the other? Should we do both?

In the end, I don't think it's a matter of picking one over the other so much as ensuring you have more than one pair of eyes looking at the code you've written, however you choose to do it. When your code is reviewed by another human being -- whether that person is sitting right next to you, or thousands of miles away -- you will produce better software. That I can guarantee.

Reginald Braithwaite writes consistently great stuff on his blog, but I think my absolute favorite thing he's ever written is We Have Lost Control of the Apparatus.

But we programmers have lost and we must be realistic about things. The fact of the matter is this: people own their own computers, and our applications are no longer the primary way they learn how computers ought to work. I know, I know, they stare at our work for eight, ten, or twelve hours a day. So you would think that we would set the standard for how computers ought to be. But the Good Old Days when most of users had never seen a computer before work have gone. Some of our users, fresh out of school, have already been using computers for ten years!

As if that wasn't enough, the really bad news is, when our users go home they have this thing called the Internet. I know, IT locked that down in the office. But we can't stop them from getting on it at home, on their mobiles, and now even on those insidious Apple iPods! And when people use the Internet, they are actually using other people's applications. I'm not kidding. Our users are being exposed to applications we don't control. And it messes things up. You see, the users get exposed to other ways of doing things, ways that are more convenient for users, ways that make them more productive, and they incorrectly think we ought to do things that way for them.

Over the last five years, the internet has evolved from a traditional HTML content delivery system into an application delivery platform. One that competes with every sort of software application, not just other websites. Every bit of software we write, on any platform, is judged against things users are already doing on the internet. We're all competing with the internet.

Reg provides a number of specific examples where internet applications have raised users' expectations. Possibly the greatest shift in expectations is around search:

[Google] is practically the home page of the Internet. Which means, to a close approximation, they are the most popular application in the world.

And what have they taught our users? Full-text search wins. If you give them a search page with a field for searching the account number and a field for searching the SSN and a field for searching the zip code and a field for searching the phone number, they want to know why they can't just type 4165558734 and find Reg by phone number? And right after we make that work for them, those greedy and ungrateful sods'll want to type (416) 555-8734 and have it work too. Bastards.

I have tried explaining that there's an ambiguity if an account number is also 4165558734. They think we should just show them what we find and let them sort it out. They're idiots, obviously, but they're our idiots and I'm pretty sure that if we fire them all we'll have to clean our own desks out the following day.

This is particularly hard on the internal applications Reg seems to be focusing on here. Internal apps are already the shakiest part of the software ecosystem; as Joel points out, lots of internal software sucks pretty badly. (I know because I've certainly written my share of it.) Having this pervasive, instantly accessible world of reasonably good software available through your browser-- and it's only one tiny click away -- is like pouring salt in the user's wounds. It's impossible to justify the pain of badly written internal software when there's a universe of better choices practically beating down your door, even on locked down corporate desktops.

If I was a user, I'd be angry, too. If you're writing software that you want users to actually use, then no matter what kind of software you're delivering, you better pay attention to your online competition. It's going to be rough, even for commercial desktop applications. I'm not sure many internal applications can legitimately compete with superior options emerging on the internet every day. It's survival of the fittest alongside a vibrant new species of internet competitors -- does your software deserve to survive?

I encourage my coworkers to lock their computers. Security, after all, is everyone's business. But often gentle encouragement is not enough. Sometimes, more.. persuasive methods are necessary.

I first learned about the noble art of goating from from Omar Shahine:

We have this problem in Hotmail. If you walk away from your desk, even for a brief moment, and your PC is left unlocked, someone will walk in, and send mail to a broad distribution list with something silly. Like "I like oranges", or worse things, some downright embarrassing. For some reason this is called "Goating". I find it incredibly annoying. My office has a lock on the door, so I am in the habit of keeping my door locked when I walk away.

Goating techniques vary from insidious and subtle to invasive, borderline vandalism. I prefer the milder forms:

• Installing the bluescreen screensaver.
• Replacing the desktop with a screenshot of the desktop, and hiding all the visible items on it.
• Switching the mouse from right to left handed.
• Using the video driver settings to rotate the display left, right, or upside down.
• Switching the keyboard layout from QWERTY to Dvorak (or vice-versa).

Goating can be quite literal. I once walked back to my computer to find this:

It's disturbingly common here, which is why I've learned to reflexively press Windows+L when I get up from my desk.

One of my all-time favorite goating techniques, however, is to install the Clippy parody applet on a victi.. er, coworker's machine. Who doesn't love our old pal Clippy!

After one particuarly inspired installation of Clippy, an email titled "What The Heck" went out to all employees:

Is this another prank or something? What the heck is this … It's rude.

Look at the right hand corner of this image.

So far this stupid thing has told me:

1. My typing speed is slow.
2. My productivity has been decreasing, I hope everything is Ok?
3. My posture is degrading and I should reposition myself.
4. Finally: It's time to play a game. Let's play hide-and-seek?

Much hilarity ensued, and more importantly, crucial lessons were learned about computer security by all.

It's up to each of us to go forth and spread the good word! If just one person learns how important computer security is, your work here is done. Many additional goating techniques can be found in these two metafilter threads; Office Poltergeist looks quite promising, as does ErrMess. And you really can't go wrong with Clippy.

But don't forget to lock your computer while you're out there spreading the word.

Since I started at Vertigo, here are a few of the projects I've worked on:

• Michelangelo
• Nash
• Whiskeytown
• Gobstopper

These are our internal project code names. The names are chosen alphabetically from a set of items; every new project gets a name from the set. We start with A, and when we finally arrive at Z, we pick a new set of items for project name inspiration. Can you guess which set each of the above project names is from? No cheating!

We've come up with the following loose guidelines for project naming:

1. We prefer one word names.
2. They should be relatively easy to pronounce and easy to spell.
3. They have to be client friendly.
4. They should be globally unique across the company. No duplicates.
5. We need a reasonable number of items in the set to choose from, in A-Z order.

Of course, no entry on naming would be complete without a reference to the classic Salon article from the pinnacle of the dot-com craze, The Name Game:

In the end, however, attempting to quantify the benefits of a naming project may be just as small-minded as, well, attempting to quantify the benefits of a name. For the lucky client who truly clicks with his or her namer, the collateral benefits go far beyond nomenclature. There are new words to learn. Fun games to play. And, in the case of the Monkeys, unimpeachable warmth and love. "We got so much more than a name," says Robin Bahr of 98point6. "I mean, I got a name for my daughter. One of our senior executives identified strongly with 'Mescalanza.' No one calls him Jim anymore. His name is Mescalanza." Meanwhile, she says, "our senior manager for Internet development just fell in love with the name 'Jamcracker.' And so today, the Harvey meeting is known as the Jamcracker meeting. There are 300 people at this company who identify Jamcracker with Harvey."

Bahr claps her hands over her mouth. "Oh my God," she says. "I forgot. I shouldn't be mentioning these names to a reporter. Technically, we don't have ownership of those names. Jamcracker is still the Monkeys' property."

Bahr stops for a moment, as if listening to herself. Then she bursts out laughing. "Listen," she says. "I take it back. You write whatever you want to write. If someone out there wants to name their company Jamcracker, God bless them. And good luck to them."

The challenge, then, is coming up with new sets to inspire project names. We began with Microsoft's list of project code names and Apple's list of project code names as our spirit guides.

Here are some of the sets we've considered for project naming at various points:

If there are there any sets I haven't listed here that you think would make for good project names, feel free to link them in the comments.

It's always fun to pick out a new name when starting a project. It's amazing how quickly we plow through an entire A-Z series in a set; we've been through almost four since I started in 2005. That's how we do it. But how do you name your projects?