mur.mu.rs

Tag: Product Engineering

How to fail

By Mike / On / In Knowledge

The title says it all, doesn’t it? In my time in this industry, with the things I’ve worked on, the stories I’ve heard, and the apps I’ve seen, I’ve found certain patterns, certain themes that recur, as fast routes to failure. If you’re doing, or planning on doing, one of these things, be warned.

Make a game.

When people tell me they’ve made an app, I say, “great!” but when they tell me it’s a game, my face falls. I hate giving people bad news. I hate telling people their app is going to fail. I hate having to tell people their games suck, and they always suck. You have a game? Sorry.

Games have to be fun, and game makers have to be brutally honest with themselves about whether their games are fun. If that were easy, the world would be crammed full of great games, instead of being crammed full of crap and copies.

This is why I warn people from writing their games in OpenGL. It just makes it even harder to code a game that is fundamentally unplayable. You should be writing your game on index cards, and playing with your friends, before you ever write a line of code.

Once the game is fun, whether you’ve developed an original concept or are remaking a classic, and once you have the thing coded, you’re maybe halfway there. There is so much extra work that has to go into making a game. So much polish. So many details.

Did you work with a team of people, including character designers, game designers, level designers, and play testers? Of course you didn’t. You probably didn’t even think about it. That’s why your game sucks.

Making games is hard. Everyone wants to be a toymaker, but few people have what it takes to actually pull that off. One of these days I am going to sit down and write down everything I’ve learned on the subject of making games, but it’s more like a book than a blog entry.

Start a social network.

Did I say everyone wants to be a toymaker? That’s only half right. The other half wants to create social networks. Ten years ago it was search engines, but now it’s social networks.

That’s because incorporating social networking has been the easiest way to make your idea sound fundable. The problem is, there is only room for three social networks in the world, and they already exist.

Don’t believe me? Here they are: There’s the realtime social network, which used to be the telephone, then ICQ, IRC, AIM, and eventually Twitter.

There’s the scrapbook social network, which morphed into the personal homepage, then Geocities, then Myspace, and now Facebook.

Then there’s the other social network; the only one properly called “the” social network. That is your actual social network: all the people you know, and the people they know. This remains pretty well locked up in your address book.

Nobody wants to sign up for another social network. Nobody wants to be part of your social network. Your social network has nothing to offer them. No, it doesn’t. The existing social networks are generic services that do not focus on, but are good enough at, your specific area of interest, and everybody is already on them. Nobody wants to switch.

This is good news! You are freed from having to do this odious, server-heavy task. Build your social features on the existing social networks. Go beyond the drop-in “share” button. Get clever with it.

The Appsterdam.rs member site is all backed with Twitter lists. At a previous company, we built a Twitter client that used a middleware layer to add features to Twitter, including the now-standard location, and the then-tenuous uptime.

That architecture was designed so that nobody had to sign up for a new account, and if Twitter went away as we all feared it might, our users would just go on tweeting. It was a good strategy then, and it’s a good strategy now. Don’t replicate, encapsulate. Don’t subclass, compose.

Run a server.

Speaking of running a server, the easiest mistake for you to stumble into is getting screwed on the backend. That’s because most people on the app side of things, which is to say the client side of things, don’t even think about the server.

If your app is touching the server, and you own that server, you are now running an enterprise backend. Yes you are. I don’t care how lightweight or simple your use cases are. If customers are touching a server, it’s enterprise.

You cannot and should not be doing this yourself. You need an enterprise team. These guys are hardcore specialists, and expensive. Requiring a server is the fastest way to require funding.

If someone hires you to make an app for them, and it touches a server, consider any statement about that server to be a dirty, dirty lie until you see it yourself. I won’t take a job with a server until I meet the backend team and convince myself they are not a bunch of yahoos. Never again.

My advice for servers is the same as my advice for social networks—use somebody else’s. Leverage data and services across the network. That’s what the Internet is all about.

Let me stop you.

There’s a kind of hypocrisy in my telling you not to do things that I myself have done, sometimes successfully. It’s the same way I tell people not to become engineers. It’s because I firmly believe if you are meant to do something, you will do it no matter what I, or anyone else, tells you.

If you don’t have the passion to ignore naysayers, you certainly don’t have the passion to succeed—especially at building something as difficult as a hit game, stable backend, or viable social network.

Eighty percent of the people working on these kinds of projects don’t have the passion. They think they do, but they don’t. They don’t have the patience to take as long as it takes to do it right. They don’t have the humility to get help in fixing the things that are wrong. The don’t even have the critical eye it takes to be honest assessors of their own work.

And there are real opportunities out there. You just have to be prepared to go into a project you may never come out of to pull it off. Want an example? I often say ideas are worthless, so here’s one of my most prized:

There is still room for a server-backed social network based around games. Think chess by mail. Now think chess by Twitter. Now think every great game being played with your friends asynchronously over the network.

This future empire is still ripe for the building. I thought Words With Friends would pull this off, but they ended up pretty much sucking in the long run. There are a lot of players trying—Plus+, Game Center, and Facebook off the top of my head—but nobody has managed to be the standout in this space.

We have a basic human need to communicate with each other. We start conversations, not because we have something to say, but because we want to keep in touch with each other, to reach out to our loved ones to say nothing more than “ping.”

When you think about it that way, isn’t a game a kind of conversation? Rather than inventing something to talk about, we break out a board game. Now make that asynchronous, and inject it into online social networking.

What is an app?

By Mike / On / In Appsterdam, Technology

When we talk about Appsterdam, we talk about App Makers, but what is an App Maker? And what exactly are these “apps” they are making? Common misconceptions are that “apps” refer to “Apple” or are something specific to mobile. The real answer is more interesting and more complicated than that.

To understand apps, you have to understand machines—not just the current state of machines, but the complete timeline of machines, from their inception, to their foreseeable future. I have a nice Keynote sequence I use to demonstrate this in my “Product Engineering” presentation.

Machines are actually older than mankind. They were invented by some clever ape who used a stick to fish a termite out of a rotten log. Thus was the world introduced to the first machine, and with it the meme of using tools.

At first tools were simply repurposed bits of nature, but when hominids took to the task, they specifically modified these bits to create better tools, chipping off bits of stone, for example, to create a better knife or arrowhead.

When we skip forward again to the dawn of recorded history, we see complex machines, purpose-built from smaller, interoperating parts. With this we have the introduction of craftsmanship, of artisanship, as tools are expensive, and prized, and the people who make them are valuable to society.

With the advent of the industrial age, and the introduction of interchangeable parts and assembly lines, tools became cheaper and more accessible. We gained the economies of scale. Machines gained the notion of configurability. By changing the machinery that produced new machines, new types of machines could be created.

Then a brilliant mathematician named Alan Turing had the realization that, with a large enough number of fast enough switches, we could create a universal machine, which could be reconfigured, or “programmed” to be any number of tools. Thus was born a new class of machine, which we now know as “computers.”

Computers eventually became small enough to fit on a desktop and cheap enough to fit in a family budget. Rather than something for governments, they became something for people, and the era of the personal computer signaled a new era for machinery—a universal machine in more ways than one.

That trend has continued to the point where computers are things we carry in a pocket, or in the crook of an arm. Beyond merely being personal, we now bond with these machines, as they become not just features of modern life, but a part of ourselves. This is the era we live in, the age of apps.

Looking into our wildest imaginations, we see a time when we are engineering on the molecular level, when machines are themselves made of nanomachines. Hardware and software cease to be distinct concepts when we can change not just how a machine behaves, but what a machine is.

How we turn a book into a piano.

We do not yet have the ability to turn a book into a piano, except that we do. In the context of the entire timeline of machines, something like an iPad becomes less like the Colossus and more like a poor man’s nanocolony.

This represents a fundamental shift from old-school “applications” running on a computer to the new software: “apps” that transform hardware to provide a complete experience. An app is an experience encapsulated in a product, the magic necessary to turn a piece of glass and metal into anything we need it to be.

Apps are transformational not only to hardware, but also to the way we do business. App production lends itself well to an artisanal economy of small businesses that cooperate with each other. We can proffer explanations of this, such as freedom from the demands of physical manufacturing, but it is largely phenomenology.

It seems not to matter so much what an app runs on as where an app comes from. Great apps come from great artists, who tend to be part of a great community. To a large extent, Apple’s success in this field is attributable to the community of developers who work on their platform.

But Apple doesn’t have a monopoly on quality, nor on culture. The things that make great apps are universal, and meant to be shared. Everyone deserves great apps. It is a firm belief in that idea that has Apple veterans joining with App Makers of every stripe to share their knowledge with anyone who will listen.

And I do mean anyone. We talk about App Makers, rather than developers, or designers, because it takes more than development and design to make a great app. Making, selling, and maintaining an app also takes businessmen, project managers, marketeers, lawyers, domain experts, and a very big sacrifice from our families.

Something has happened over these last four years. We’ve done an about-face, stopped looking toward the past, and started the business of building the future. That’s what it takes to be an App Maker, and that’s who it takes to make an app.

And our children programming robots

By Mike / On / In Technology

You know what I love about Android?

One thing: the mascot. How can you not love Andy the Android? It’s the one thing they really got right; the one well executed detail they didn’t just copy over from iOS.

Seeing Droid Charge as the promoted topic on Twitter made me realize what an opportunity they missed with their whole branding.

What if, instead of a Droid Charge, it’s a Charge Droid, another in a long line of cute little robots that do useful things for you.

Smart Phones are for nerds, and iPhones are for nerds in turtlenecks. People love robots, not big scary robots, but cute, slightly buggy robots, like the Star Wars droids from which Droid licensed its name.

George Lucas and his crew get how to make a robot friendly, even lovable. Google and their crew do not.

The robots in the Droid commercials are scary. Disembodied alien arms researching humans using the Minority Report fork of Android. Horrifying.

Ask a nerd to design a robot and he’ll design the perfect killing machine, programmed to punish purveyors of wedgies worldwide.

That’s not the kind of robot people fall in love with. That’s the kind of robot people fear. Getting people to fear technology is not the challenge.

Imagine if a Droid actually looked like Andy, and behaved like him too. Imagine if the Android SDK was for programming an android instead of a cheap iPhone knock-off.

Imagine if Google bought Tapbots, and our children programming robots.