Four stages of shipping

I’ve experienced the four stages of grief — denial, depression, anger, acceptance — but recently realized that there are four stages to shipping, too:

  • Relief
  • Exhaustion
  • Fear
  • Acceptance

In relief phase we are all just happy to be done. The product is out the door. There’s a little adrenal kick that goes along with it. This phase never lasts long.

Then exhaustion sets in. It’s been a long road and invariably the hours have been tiring. 6, 7 days per week, 10 plus hours a day, dreaming about code when asleep, awake early, asleep late. The exhaustion mutes the brain, though, and lets a day or so pass with some rest.

Once the brain starts to recover a little then fear sets in. What’s broken? If it’s broken am I going to be able to fix it? Is anyone going to care? Will we have downloads? Did I remember to do this or that? Did that last minute change cause a problem? I never did retest this one section. I’m sure that was broken! The reviews are going to be horrible.

Finally, with time, acceptance sets in. Well, it will do what it does. If there are bugs we will fix them.

And that’s when we start planning the next build.

Indie Game: The Movie

Indie Game: The Movie is an incredible documentary on the making of indie games. (I saw it on Netflix.) This documentary followed a couple of game developers as they worked toward release. They each worked on their games for years, often five or more. These aren’t fail fast inventions. They are full of love and attention, a craftsmanship that we have lost in other fields.

I love this quote from Jonathan Blow:

Part of it is not trying to be professional. A lot of people come into Indie games trying to be like a big company. What those game companies do is create highly polished games that serve as large of an audience as possible. The way that you do that is by filing off all the bumps on something. If there’s a sharp corner make sure that’s not going to hurt anybody if they bump into it. That creation of this highly glossy commercial product is the opposite of creating something personal.

Things that are personal have flaws, they have vulnerabilities. If you don’t see a vulnerability in somebody than you probably are not relating to them on a very personal level. It’s the same with a game design. Making it was about, let me take my deepest flaws and vulnerabilities, let me put them in the game and see what happens.

I spent years worried about appearing small. But I’ve come to understand that being small is fine, and in some ways has its advantages. We are small. Being who we are is perfectly fine.

Contingency planning

My brain whirls all the time. I can hardly make it stop, even at night. It wakes me up at 3 or 5am and I have to read a book for a while before I can fall back to sleep.

What does my brain work on all the time? Plans and contingency plans and contingency plans for my contingency plans. They are ten levels deep, at least. I think through so many cases that I often come across as unflappable. That’s because I’ve already figured out what I would do in every situation. In the moment all I have to do is execute.

This is a big year for Infinity Softworks. The question we have to answer is whether Infinity is a full-time job for Rick and myself or whether it is a part-time job for one or both. There is revenue coming in but not enough to support both of us full-time at anything close to market wages. While neither of us are expecting to get to market wage this year, this is the year we need it to show promise.

In particular, that promise has to come from Equals as the other products are what they are at this point.

So I make plans. When will Equals be released? What revenue do we expect from DEWALT Mobile Pro? How about our deal with ETS? Will that change next year? Is the powerOne revenue sustainable? Any way to grow it? What do we need to make from Equals? Where do Rick and I need to be financially? When? What other expenses are we expecting? Any we can cut? Any we missed?

When all is said and done, I see revenues with modest raises this year for both of us. That’s a start, especially considering I (hopefully) low-balled DEWALT revenues and have no income from Equals this year on the books yet. But a sizable chunk of this year’s income comes from contract work and one-time payments, something I don’t want to do after this year. Equals needs to replace that.

Which inevitably leaves me contingency planning January of 2016. What happens if we have the incomes? What if we don’t? But this one needs to be pushed away for now.

All this planning can be a big distraction, too, especially at 5am. Enough planning. I need to execute.

The technology behind our Mobile First Cloud First strategy

Excuse my particularly nerdy topic today. This is an exception for me but felt it important to outline what technologies we are using to make this strategy work.

The problem with being Mobile First Cloud First as a tiny little indie developer company is that you have to become proficient at a bunch of different technologies. This is hard for a single developer or two-person team to accomplish.

We are currently developing for three platforms using five technologies. The three platforms are the web, iOS and Android. The languages are Javascript, (ansii) C, iOS/Objective-C, Android/Java and Ruby on Rails. The technologies, besides Javascript and C, don’t matter that much specifically, although writing for iOS and Android leave little choice.

Have you ever really looked at a map of Florida? I mean really looked? In the middle of the state is a massive lake, Lake Okeechobee. It’s so big that it is actually the primary source of fresh water for all of south Florida with tens of millions of residents. When I was in high school in Ft. Lauderdale I remember hearing that Lake Okeechobee was so shallow, though, that you could walk across the entire thing without ever having your head below water level. I’m sure that’s not true¹ but I love the metaphor. That’s how I am as a programmer: miles wide and inches deep. I know all four languages pretty well (my partner does all the ansii C development) but in none am I an expert. Allowing myself to just be proficient is important to pulling this strategy off.

The one that I am probably best versed in today is the most important to make this cross-platform strategy work: Javascript. It’s the primary language we have that works across all devices. And lucky for us it has gotten awfully good over the last few years. We use it in specific views, never for view transitions, minimizing the places where it is obviously not native code.

Within those views we do have some animations and a few controls.² We consciously decided, however, not to match the look-and-feel of native controls. Instead we created our own that function well but don’t try to be the same. I suspect most of my customers won’t really notice the difference.

As much as we could develop in cross-platform code we did. That means big chunks of the UI are in Javascript and big chunks of the back-end technology are in C. This allows us to treat the “native” code as glue. On the web that glue is Ruby on Rails, although it could be Python or Go or node or whatever. For the most part it handles JSON callbacks, serves pages and interacts with the database.

On iOS and Android, the framework for the apps is all native and only a single primary view is HTML. This one page, though, is 80% of the UI work to develop and maintain the app. Thousands of lines of code are all cross-platform. Furthermore, we stuffed as much of the processing into C as we could, which will link into Rails and Android and run natively on iOS. The key is being able to make quick updates to all apps.

If you are just starting out, I highly recommend the following resources for iOS, Android and Javscript:

Objective-C Programming: The Big Nerd Ranch Guide (2nd Edition)
iOS Programming: The Big Nerd Ranch Guide (4th Edition)
Android Programming: The Big Nerd Ranch Guide
How To Learn Javascript Properly
Agile Web Development with Rails
Railscasts

Becoming proficient at multiple languages is time-consuming but important to our success long-term. We can keep churning on the same ol’ mobile-only apps we have, making a few bucks a month, or take some of that time and start learning technologies that let us be mobile and cloud first. I think the latter is the only way to sustain success.

¹ Besides, I think the alligators would probably get you before you made it across.
² Check out Greensock, especially in the iOS and Android browsers. Amazing stuff.

“Mobile First Cloud First”

Ben Thompson’s Mobile First post is an interesting read and his perspective is always fascinating. (I pay $100 per year to be a member. I can’t recommend it enough.) It’s not the post itself that has me thinking, though, specifically, it’s footnote #4:

Microsoft’s “Mobile First Cloud First” strategy makes much more sense now, no?

Here’s the thought: can you really be mobile first without being cloud first? Mobile first means everything you do is different because people have a computer in their pockets all the time. (And by people, I mean all people on the planet in the next few years.) What enables mobile first, though, is that every one of these devices is connected to the cloud, and its the cloud that lets us connect outside the device.

So can you have one without the other?

I think a lot of us indie developers have tried for years to be mobile first without being cloud first, and I think that is part of the reason it has been so hard to make a living. Infinity Softworks is a perfect example of that. It came to be in the mobile era. I wrote my first apps for PalmPilot and later Windows Mobile, and we have made the bulk of our revenues over 18 years from selling apps for mobile devices.

The first generation of our products were fixed. It had a certain number of bundled calculations and that was it. But that was okay. The devices were underpowered and completely disconnected from the Internet.

The second generation of our products had some bundled calculations but also allowed customers to write they own. They were still on disconnected devices, though. Yes, you could email a file but that is a far cry from being Cloud First. Again the devices were largely disconnected though, at least they were until 2007 when we wrote a BlackBerry version, and then 2008 when we could write for iPhone. Over the past few years, though, those connections have only gotten better and more pervasive. Our apps have not.

Even to this day powerOne is primarily a stand-alone application that has very minimal connection to the outside world. The only cloud connection it has at all, besides emailing results and formulas, is an in app library of calculations you can download from, but even that is buried at the bottom of the home screen in a tiny button. It’s hardly front and center in the product.

These first two generations were Mobile First, but neither one was Cloud First. Over time, as the devices have gotten better and faster connections, our revenues from powerOne have waned. I’m thinking there’s a connection.

A few years ago we set to work on the third generation of our products (a little at a time). We started out writing mobile apps but about a year ago we switched and started developing the web version first. While I didn’t have words for it at the time I sensed that the cloud was important to making a sustainable product and that by developing a web version first it would help us shift our mental framework.

Now we think in terms of systems rather than mobile apps. For the first time I believe we are thinking Mobile First Cloud First, and I believe it will have a huge impact on our fortunes.