Full-Time Indie iOS Dev and Music Enthusiast: A Top Dev Interview With Alex Andrews

Running TenKettles

Tell me about Ten Kettles. Where did the name come from?

I’d started a band the year before and we needed a name. I came up with the idea “Ten Kettles” but it didn’t make it past the chopping block. The name stuck with me though and I thought it worked even better for a company name.

The kettle imagery itself came from a few sources. My background is British (first one born in Canada), so obviously there’s the tea element. But also the land that Toronto sits on was “purchased” (I use that term very loosely) from the Mississaugas of the New Credit a couple hundred years ago. The deal involved a couple dozen brass kettles, which stuck with me for some reason.

So, I think between the family and city history, I just liked the linkage to something bigger. It’s kind of a reminder to myself to stay aware of that bigger responsibility too. I guess the name reminds me to always try to do the right thing.

Do you have any working partnerships?

I work with a fantastic designer on most of my icons, website design, and the design of our upcoming app for drummers, BeatMirror. His name is Joel Derksen and he’s great! The icon he made for Ten Kettles actually just won a big logo design competition, so we’re super pleased.

I’d really like to build a relationship with a great Android developer, but haven’t quite decided about the Android route yet. I also talk through company decisions big and small with my wife Alicia; being able to bounce ideas around with someone so smart and thoughtful is definitely a huge asset. Very lucky!

How do you prioritize the work at Ten Kettles? For example, when do you work on hearEQ and Waay and then move on to a different product?

I like working linearly—one thing at a time—and in relatively small chunks (usually two weeks for a deliverable). In terms of which task I choose to work on, I look at a bunch of factors:

• Am I confident users will want it? Maybe I need to gather more info first (e.g., customer surveys)
• Is it urgent? (e.g., stripping out Parse before it disappeared)
• Will it make money? (e.g., I’d genuinely love to spend two weeks tweaking animations or improving test coverage, but that might not be the most profitable use of my time)
• Will it actually take two weeks? Or should I break it up into smaller parts…
• Is it newsworthy? If an update can get some good press, that’s a huge deal!
• Am I excited about it? This isn’t always that important (my dev-self doesn’t always love my CEO-self’s decisions), but it helps to break a tie.

So, I order (and endlessly reorder) potential projects based on these things, and then every two weeks I pick what’s on the top of the list to do. I generally avoid changing course until two weeks later, then it’s onto the next thing.

What tools do you use to help with the planning of product work?

At first, I was going to give a list of software tools, but to be honest I think the biggest tool is a regular biweekly schedule. Every two weeks I take a day or half-day to work through potential project ideas—like adding a feature to hearEQ or building out a new app—prioritize them like I’d mentioned before, and then plan the next leg of work.

I think taking a day away from code to do this stuff is probably the most powerful thing, and helps me to take off my dev hat for a day. But, in terms of physical or software tools, I’d say Sublime Text, Pages, OneNote, and lots and lots of post-it notes!

Alex’s variant on scrum

At Ten Kettles, you must have to deal with the admin work, planning, development, design, testing etc.. how do you manage the wearing of multiple hats?

The New York Times’ VR app.

Last year I freelanced on two projects with a fantastic studio in Toronto called Secret Location. I was working on virtual reality apps there, including rebuilding the New York Times’ VR app from scratch in Swift (I loved working with their designs! Beautiful fonts.).

But unexpectedly, I think my biggest takeaway wasn’t technical but was a new project management technique. They used Scrum, which I hadn’t really used much as a solo developer beforehand. I got really into it and read a bunch of Scrum books while I was there to learn as much as I could.

But Scrum’s really meant for 5–9 person teams, and in my product work, I’m usually just the 1. I kept thinking how I could adapt this to my work, so as soon as the project was done, I flew off to Montreal (one of my favorite cities) for a few days to shut myself off from the world and try to come up with a 1-person variant. A few days later, it started to come together and I’ve been working with my “ScrumOfOne” variant ever since.

Though I’ve been quite happy with how “ScrumOfOne” is turning out, the most important element is really the core Scrum philosophy, more so than any tweaks I’ve made to the day-to-day methods. For anyone interested in learning more about that, the book I started with and would definitely recommend is “Scrum“. There are many books out there, but I did find this one laid out the philosophy and key methods in a pretty motivating way.

So, to (eventually!) answer the question, I use scrum techniques to keep organized. That means a super-quick turnaround from idea to development to getting it out to users. I try to get everything out of the way of this goal. Admin stuff usually gets done in my first hour of the day, before I jump into code. I usually work directly with a designer, so I don’t do too much design myself anymore. And then I pull the planning out to a full or half day every second Friday. That leaves me lots of time to build products uninterrupted.