Mobile Development and Aggressive Testing: An Interview with Josh Michaels


JM: That was the core inspiration. Inspired by I guess would be how we would say it, but yeah it was definitely...

JV: The movie and the life combined to an app.

JM: It was common on the App Store, right?

JV: Right.

JM: In a lot of ways, at the time the App Store, Idiocracy and fart apps were ruling the charts that time. Now it's a casino, so I guess that's kind of Idiocracy. It is what it is. It's still an amazing place to make and sell software.

JV: You're now concentrating on Magic Window. How many people work on an app, something like Magic Window?

JM: In Magic Window's situation I work with an amazing photographer by name of Al Bergman who does the vast majority of the photography for the app. I would say aside from all the software-related stuff, he is the other primary dude at this point who works on it. Software development-wise on iOS I do all the development, design work, and pretty much everything other than the photography. On Mac I've got some help from a friend who does some of the harder dev work related to graphics programming, which I don't have skills to do.

The intent is that you've got to build something that can only use very few resources because if I have to start paying a lot of people, these apps don't make that much money. This isn't like a massive gold mine unless you set out to make something that's intended to make a ton of money. If you're going to do that, make a casino game. It's not hard. We have to be really scrappy; that's the name of the game. I think it would surprise a lot of people to see just how scrappy we are and have to be in order to keep this thing going. It'll be Magic Window's four-year anniversary in April 19th. Four years is a pretty good run for that product.

JV: Yeah, totally. That's a good life cycle. Do you use an agile development methodology when you do the development stuff?

JM: I work on the way I work. When I worked in bigger software organizations we worked under so many different methodologies and I got to a point where I was like well, I like to come up with a methodology that works best for the people involved. Every company, every organization, every group is different and different techniques for different places. I would say that I work under an extremely iterative methodology and rather than spending a lot of time drawing something down in advance just go build the simplest possible version of it and keep tweaking it until I get it right. That usually gets me there a lot faster than sitting around with a pen and paper trying to come up with the right interface. As soon as it's functioning you start to see things that you can't see on the pen and paper so I try to get to functional as fast as possible and then iterate from there.

JV: That's what I was thinking because I'm assuming that you would take the aspects of that methodology, but you're not exactly going to be writing on a big board for you and your photographer or anything.

JM: That's not to say, though, that these things don't happen in some form. We have Google Spreadsheets that track our aspirations for what scenes we want to capture, and that's similar to writing out on different cards, here's the different scenes that we want to do and different scenes that have been requested by customers. Some of that comes in but a lot of what makes what I do possible is by condensing it down to just a couple of people. A lot of the overhead that comes with bigger software isn't there. I can get done in the time that it would take me ten meetings before I can make a decision like that.

We spend a lot of time snowboarding. We actually released Tahoe Blue last year, which was an ode to life living in Tahoe working on software. We had a policy where we would make certain decisions on the ski lift where we'd get on the lift, it'd be like we're going to make this decision before we get off the lift. Let's go. It's like wait, we can't make that. I was like, no. We've been sitting on this decision for three months. We can't make up our minds. We've got all the available information we need. We're going to make this decision now. Let's go. We got to make the choice by the time we're off the lift. We try to be extremely aggressive with decision making and just not wallow, sit around and think about stuff too much. Just make the decisions and go.

JV: It's interesting that when I talk to a lot of people working in enterprise software, there's always a disconnect between the business and the developer. Given that you're a small organization, how do those two things merge? You are now dealing with both the business and development.

JM: I think it's tricky because the developer in me will often want to do things that the businessman would say absolutely no to. I think one example of that is automation. There are a lot of times where I'll be in situations where it's like man, I'll save myself some time overtime if I build some automation here to help me speed some things up. At the end of the day, the amount of time it takes to maintain that automation often ends up exceeding the amount of time saved through the automation and for the most part, every time I've tried to optimize through automation it's ended up costing more than it saved. Just trying to execute as fast as possible and only doing bigger scale optimizations like that when they're really justified.

JV: Let's talk about a little bit about testing. What type of testing do you do for your apps?

JM: I'll talk about that in a couple of different ways.

JV: Yeah, go for it.

User Comments

1 comment

About the author

Upcoming Events

Nov 05
Nov 14
Dec 05
Jun 03