Introducing DEWALT Mobile Pro for Android

I am proud to announce that we shipped DEWALT Mobile Pro for Android last week. It is available from both Google Play and Kindle Appstore.

While the basics are the same, a wonderful scientific and unit calculator, a few free templates and a number of additional packs that can be purchased in app, the Android version has been completely re-written from scratch using some of the technology we’ve developed for Equals. The app itself is much cleaner and, hopefully, much simpler to use.

If you are interested in where we are taking our products, you might want to take a look. Even if you don’t have an Android or Kindle device, there are multiple screenshots available to review. And if you do have an Android or Kindle device, please download the app and give it a nice review!

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

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.