Got an Android or iPhone? Pull it out right now. Are there more games on it than enterprise business applications? We’d bet that way. And yet both are software, and both are built by developers working in teams with deadlines. What can your developers learn from game developers?
George K. Mathew, president and COO of business intelligence firm Alteryx, said that enterprise applications tend to be stodgy and boring, even though they really don’t have to be that way.
“When you look at the enterprise applications that are in market today, they’re horrible experiences, both for design time and run time,” he said. “You’ve got people who are trained on great video games, all the way up through their 20s and beyond, and you enter the workforce, and you have these amazingly horrible experiences in your enterprise applications. I think [Salesforce.com CEO] Marc Benioff deserves credit on this. He said that just like there was an Arab spring, there is going to be a corporate spring where people will just revolt against the applications in their enterprise.
“I think it started with mobile. The applications are better than they were two or three years ago. People want better enterprise experiences.”
The power of easy user interfaces is a big pull for the appeal of video games. The popularity of games with simple interfaces across the history of video gaming is an indication of what people gravitate towards. Tetris, Pac-Man and recent Scrabble clone Words With Friends are all examples of games with very simple interface paradigms and widespread appeal and popularity.
Consider the interface of Pac-Man: a single joystick. Up, down, left and right are the only options available to the player. While gameplay elements such as power pills and ghosts offer dynamic and shifting play experiences, the user is still only presented with a simple, clear interface.
Tetris is another example. The rotate buttons add to the traditional joystick directions, but the gameplay is entirely generated from the complexity of fitting four-square blocks together.
Mining for ideas
Another example of simple interface design winning over players is the popular indie game Minecraft. This blocky 3D game offered players a very simple-to-use interface for building incredible structures. Using the standard interface of first-person shooters (mouse and keyboard), Minecraft players have constructed scale models of the Starship Enterprise, in-game art, and an almost infinite number of castles. Minecraft sold millions of copies online as nothing more than an alpha, and has subsequently reached version 1.0 thanks to millions of dollars in revenues for Swedish startup Mojang.
And in the story of Minecraft, another lesson can be learned by enterprise developers: Talk to your users often. In the case of Minecraft, the game’s creator, Markus “Notch” Persson, offered the game to the public as an alpha, and then responded to user demands and criticism with each successive release.
The alpha release of Minecraft also allowed Persson to charge for the game long before it was worth the purchase price. At US$16 initially, the price rose with each passing development phase. So successful was Persson’s pricing structure and release cycle that PayPal couldn’t keep up with the massive amounts of money his company was raking in every week.
Or course, Minecraft isn’t that different from an enterprise application. It is written in Java, and all players contact a central validation server. Additionally, end users can run the Minecraft server and allow external clients to connect remotely.
Without the graphics, you’d think Minecraft was a deployable enterprise service. And yet this alludes to another lesson enterprises can learn, or likely have already learned on their own, from the game world: one incredibly good programmer is worth 100 novices. While Persson has subsequently hired a staff, he wrote Minecraft entirely on his own until just before the beta phase. By that time, the game had sold almost a million copies.
Minecraft’s other major selling point is the fact that it allows its users to be extremely creative. It’s a game about building and exploring, and players have made remarkable structures in the game. It’s this open-ended creativity that has given the game such an impressive following.
Fostering creativity is a big part of software development, too. Randall Ward, cofounder of Appfire Technologies, said that when he visits companies to help them build out their agile processes, he can immediately tell what type of development house it is just by looking at the offices.
“On the behavioral side, making your environment fun to work in is something enterprises can learn from game companies,” he said. “You walk into a game company and the walls are different, the signage is different, everything is much more visual, everything is electric and exciting. You’re vividly aware you’re within a different type of environment. I’ll walk into a GE or an Abbot Laboratories, and you feel cold, stark and dark. Whatever the adjectives are, you feel that when you walk in and that reflects on the outcome of your work.
“Enterprises that are aware of that and make it a better place to work…see returns on that. I walk into Target’s mobile group, and it’s a much more sensory rich environment.”
These are the differences between the cubicle stylings of a game company with those of an enterprise: action figures and toys for a game developer, empty coffee cups and perhaps a holiday schedule on the wall of an enterprise cube.
And this leads to a very simple and easy game-developer tactic that enterprises can adopt: release parties. Game development cycles are very concrete, and ship dates in particular are typically set in stone for a developer. They’re also set in stone right from the outset of the project, due to marketing, packaging and shipping concerns. Thus, every milestone in a game development process is extremely important.
And what better way to mark a milestone, said Ward, “than by celebrating delivery and success. Game developers have parties around releases. It’s a small aspect, but enterprise developers can learn from this. If we can celebrate our deliveries, we’ll build cadence and momentum. I see it all the time in gaming.”
Where game firms really shine in their development practices, said Ward, is in their adoption of agile development practices. He said that most of the tenets of agile are built into game development workflows. This includes test-driven development, continuous integration, and projects that blur the lines between teams.
In fact, said Ward, teams are almost a non-entity in game development; rather than being sequestered by one aspect of development all the time, game developers tend to wear a number of hats. This is because the real goal of a game development team is to ship version 1.0 as close to perfect as possible, he said.
Enterprises, said Ward, are very focused on patch Tuesdays; they tend to think of the next release, and the release beyond that, as ways of solving problems. It’s easy to say “leave that section of code alone, we’ll refactor it in a later release,” in an enterprise, said Ward. But for game developers, patching is typically not an option. The release must be complete and almost perfect, because it will be standing on its own in the marketplace, with no SLAs or long-term contracts to keep customers tied to the software. purchase game is a complete work, with a beginning, middle and end; none of these items can be omitted before shipping.
Ward said that this leads to game development teams being wholly invested in their products. That, he said, means everyone, from testers to artists to product managers, are deeply involved in all aspects of a development process. When a dangerous-enough problem is found during development, it’s not uncommon for everyone to pitch in and try to solve it.
Compare that to an enterprise, said Ward, where a single developer can horde bugs under his desk, or take a single problem on solo. And this leads to another major area of difference, said Ward: in the game development world, accountability is a big deal. This means every developer on a team is accountable for the code he or she checks in, and answers to the entire team.
Of course, accountability helps any software development process. But in the game world, because everyone involved is so tightly focused on a release date and a single goal, the teams are able to be brutally honest with each other. So if Steve writes in the development wiki that he will work on writing a new routine for treasure generation, and then Steve doesn’t get the project done by the date he set for himself, the entire team could quickly browbeat him into giving up the task, or even pressure Steve into buckling down and getting the work done over a weekend.
“Gaming companies are intrinsically more transparent with their work,” said Ward. “From mock-ups on the wall, to using collaboration tools where they put their ideas out there, they write down their ideas and are open to challenges. Transparency builds that awareness and fuels collaboration. I see it in almost every gaming environment I walk into. They expect to be challenged on everything they’re building, and they use that to build a better product.”
The Vision thing
But perhaps the single greatest difference between game developers and enterprise developers is in the genesis of projects. For an enterprise, projects begin with someone laying out requirements. With gaming, things are far more visual and creative.
“When you walk in and work with a gaming development organization, you can see the way they execute is completely different,” said Ward.
“They visualize their destinations. When you walk inside, you see lots of pictures and mocks-ups of the end product. Everything starts with a picture, and you can instantly see the evolution on the walls…They also design with reusability in mind, which is a big thing for enterprise CTOs. In the gaming world, they don’t pretend they have to start with everything new. They like reusing, whether it’s a tool for character development, or features and functionality, this notion that I have to start with a clean slate just doesn’t exist in the gaming world.”
As with any software development project, your first task in game development is to construct the tools you’ll need to build the end product. For enterprise developers, this tends to be a less archival, more green-field effort. But for game developers, old tools become new overnight.
Maxis, a subsidiary of Electronic Arts, is well-known for creating SimCity. Back in the 1990s, SimCity spawned a pseudo sequel called SimCopter, a 3D game where players could fly a helicopter around their SimCities.
Jim Siefert, project manager for SimCopter, said that during the development of SimCopter, the team created a tool for customizing the look of the primitive 3D people in the game, aka the Sims. The tool allowed for quick character customization, which was necessary for the developers to be able to quickly populate cities with non-identical people.
One of the paradigms that came out of this tool was that the team learned it would be impossible to program behaviors into each Sim’s AI code. Instead, the behaviors, actions and animations associated with the Sims interacting with an item on the map were all encoded into the item itself, rather than in the character AI.
As a result, the team was able to simply add more items during development, and never once did they have to rework the Sims’ code to make these items work in-game.
Fast-forward five years, and the character creation tool for SimCopter has matured significantly. So significantly, in fact, that it’s become a user-side tool included in a popular new Maxis game. This new game also included animations and action information in items, rather than inside Sim AI. This new, far more successful game was codenamed “The Dollhouse,” but you might know it better as The Sims.
Thus, game developers understand that tools aren’t ephemeral. A good tool can be evolved as a project evolves, and maybe eventually that tool can become customer-facing.
NEXT MONTH: How enterprises can learn from the 24/7 always-on world of massively multiplayer online games.