Under the Radar

00:00:00 ◼   ► Welcome to Under the Radar, a show about independent iOS app development. I'm Mark Orment.

00:00:04 ◼   ► And I'm David Smith. Under the Radar is never longer than 30 minutes, so let's get started.

00:00:09 ◼   ► So today we wanted to discuss what I'm kind of coining as speculative development or speculative

00:00:17 ◼   ► design. And this is coming out of an experience I had this week when I was doing some work

00:00:22 ◼   ► on my audiobooks app, where I was doing and had been kind of struggling through a lot

00:00:29 ◼   ► of the updates that I'm doing. I'm kind of doing this big sweeping overhaul of the app.

00:00:33 ◼   ► And specifically I was struggling with some of the changes that I was, like the changes

00:00:37 ◼   ► I was making was causing me to make a bunch of updates into the iPad version of the app.

00:00:43 ◼   ► And at a certain point I had this realization that I've never used the iPad app for this

00:00:49 ◼   ► app, ever. I've used the iPhone app fairly extensively in most of my testing. It's something

00:00:54 ◼   ► that I use on a semi-regular basis. But just for me and the way that I use the app, the

00:00:59 ◼   ► iPad version had never been used. And it had kind of this realization as a result that

00:01:06 ◼   ► I was kind of building this thing in a way that I really had no idea how it would best

00:01:10 ◼   ► be used. And in this particular case I decided what I really should do is I was just going

00:01:16 ◼   ► to make the iPad version of the app be essentially a blown up version of the iPhone app. That

00:01:23 ◼   ► is, which is awkward and tricky and I think it makes it a good topic to talk through today

00:01:28 ◼   ► because on the one hand I am ending up with an app that is structured and works in a way

00:01:35 ◼   ► that I know works really well on the iPhone. And the code for that is much simpler now.

00:01:40 ◼   ► There's not all of these, like if iPhone do this, if iPad do that. The app is more reliable

00:01:46 ◼   ► probably as a result. But it isn't as optimized for these particular users and these particular

00:01:51 ◼   ► use cases. But in some ways it's probably, when I was guessing people who used iPads

00:02:00 ◼   ► would like, it may not actually even be what they would like. And so you have this strange

00:02:04 ◼   ► tension between speculative like making up these features and making up a layout and

00:02:09 ◼   ► guessing a design for something that I don't actually have a strong opinion on when it's

00:02:15 ◼   ► like in theory that might be better, but in practice maybe it's worse. And I don't actually

00:02:20 ◼   ► know which one of those is better in this particular case, but I know that I am enjoying

00:02:25 ◼   ► working on the app a whole lot more now that I have just given up on the concept of trying

00:02:31 ◼   ► to make this mythical iPad version that I'm kind of projecting would be great for somebody.

00:02:37 ◼   ► And instead just saying, "You know what? I know how to make a really good iPhone version

00:02:41 ◼   ► and if you make that bigger it may not be as ideal, but it will work well enough." And

00:02:47 ◼   ► I'm not speculating. I know what works. I know how to structure things. I know how the

00:02:52 ◼   ► layout and the flow should work. And ultimately that's probably better, but it is a weird

00:02:58 ◼   ► tension and something that I think is awkward, especially when you are the developer and

00:03:04 ◼   ► designer of an application that you have to kind of, at a certain point you're always

00:03:10 ◼   ► probably doing a little bit of projection, a little bit of speculative development about

00:03:14 ◼   ► there are features in the app that you may not necessarily use yourself, but that some

00:03:21 ◼   ► of your users do use. But I think it's a really interesting area to be cautious of because

00:03:29 ◼   ► the more we do that, and there's a whole bunch of other areas that I'll probably get into

00:03:33 ◼   ► later in the show where we kind of have to do the speculative development, but every

00:03:38 ◼   ► time I think I'm starting to, as I look back on my development for the last few months,

00:03:42 ◼   ► I'm starting to see areas where I've been doing this kind of speculative development,

00:03:47 ◼   ► and in a lot of cases I end up regretting the work that I do because it's just guessing,

00:03:53 ◼   ► and it's never going to be my best work because it doesn't have the thoughtfulness that it

00:03:57 ◼   ► could have otherwise.

00:03:58 ◼   ► Yeah, I mean, I've faced this problem a lot with user feature requests. This goes a lot

00:04:05 ◼   ► into it. In the case of bigger things like your iPad app, your iPad version of audio

00:04:12 ◼   ► books, I would imagine you have the data to show that not a lot of people use it on iPads,

00:04:18 ◼   ► right?

00:04:19 ◼   ► It's certainly a minority. I think the number's about 18 percent or something like that of

00:04:23 ◼   ► users use the iPad.

00:04:25 ◼   ► That's actually higher than I would have guessed. I believe that's higher than Overcast,

00:04:28 ◼   ► but I think analytics here help, and again, you don't need massive detailed analytics.

00:04:35 ◼   ► You can just do a simple thing like what you do, just like reporting back to a server,

00:04:38 ◼   ► like am I running on an iPad or an iPad, what OS version, stuff like that. You can learn

00:04:41 ◼   ► a lot just from that.

00:04:45 ◼   ► If a very tiny portion of your customer base is using something or something that you expect

00:04:50 ◼   ► only a tiny customer base to use if you haven't released it yet, that makes it a pretty easy

00:04:54 ◼   ► decision to be like, "You know what? If I don't really want it and not a lot of people

00:04:59 ◼   ► would use it, and it's at all any work to do or maintain, then it's a pretty easy decision

00:05:07 ◼   ► to say, 'You know what? No thanks. That's probably not worth doing.'"

00:05:11 ◼   ► The tricky part is when one of those things isn't true. For instance, if something's making

00:05:17 ◼   ► it easier, like if not a lot of people would use it and it's a lot of work, then don't

00:05:21 ◼   ► do it. But if it would make some people really happy and it's almost no work and it's not

00:05:28 ◼   ► going to have much of an ongoing maintenance cost, that's a trickier question.

00:05:32 ◼   ► In Overcast I have my alert icon badge number toggle where you can have the app display

00:05:41 ◼   ► its red icon badge with the number of unplayed episodes you have. This is something that

00:05:45 ◼   ► I really don't like. I don't even think anybody should ask for this. But after 1.0 was launched,

00:05:51 ◼   ► it was one of the top requested features because the people who do want it really, really want

00:05:57 ◼   ► it.

00:06:01 ◼   ► I was already tracking which episodes are, or how many episodes are unplayed in other

00:06:06 ◼   ► parts of the API. To show that red number badge above the app icon is like two lines

00:06:12 ◼   ► of code. I figured, "You know what? I can put this checkbox in my nitpicky details screen

00:06:17 ◼   ► with a funny caption and I can have this satisfy the people who really, really want it."

00:06:24 ◼   ► Ongoing, it's really not that much work. It's those two lines of code. There's almost no

00:06:30 ◼   ► complexity to it. It doesn't really interfere with anything else about the app. I don't

00:06:33 ◼   ► really ever need to change it unless I change the definition of what an unplayed episode

00:06:37 ◼   ► is, which could happen, but it's unlikely.

00:06:41 ◼   ► So overall, that's a pretty easy thing to say, "You know what? People do want this even

00:06:46 ◼   ► though I don't and there's enough of them that it matters. I'll give it to them. It's

00:06:52 ◼   ► not that much work."

00:06:53 ◼   ► But then I have another example of a toggle in Overcast called Play Next by Priority. This

00:07:00 ◼   ► has caused me lots of headaches in 3.0, most of which are still not resolved. This is a

00:07:08 ◼   ► preference where basically Overcast playlists have a notion of priority podcasts. You can

00:07:13 ◼   ► set certain podcasts to be ranked higher than others when new episodes come in.

00:07:18 ◼   ► The question is, if you're playing something from the middle of a list and the episode

00:07:24 ◼   ► ends, what should play next? In my concept of Overcast playlists, no matter what your

00:07:29 ◼   ► priorities are, whatever's listed next in the playlist should play next. I released

00:07:35 ◼   ► one point out of this way and I didn't even consider any other possibilities. To me, that's

00:07:39 ◼   ► obviously how it should work.

00:07:41 ◼   ► But I got tons of confused people and people who requested this enhancement. A lot of people

00:07:48 ◼   ► expected that even if you're playing something in the middle of the list, when it ends, the

00:07:53 ◼   ► highest priority unplayed item in the list should play, which means usually the top item

00:07:58 ◼   ► in the list should play. Although you can reorder my list, which makes it more complicated.

00:08:02 ◼   ► But it is generally, and I did a Twitter poll a while, like years ago, like a year ago when

00:08:08 ◼   ► I implemented this feature, and basically people couldn't agree on what the right behavior

00:08:13 ◼   ► was and there were tons of people on both sides. Some people said, "Yeah, just play

00:08:16 ◼   ► the next thing in the list, logically." And just as many people said, "The highest priority

00:08:21 ◼   ► thing should play next."

00:08:23 ◼   ► So I had to add this option and what this does is make anything complicated that depends

00:08:31 ◼   ► on trying to figure out what plays next. Because I have a basic function that tells you that

00:08:37 ◼   ► off of the object, but it became a problem when I added two features in 3.0. The widget,

00:08:44 ◼   ► which shows the next two next items and the play next feature that moves things around

00:08:52 ◼   ► playlist on demand in order to play things next. This completely breaks with the play

00:08:59 ◼   ► next by priority setting on. Because the widget checks and it says, "Alright, what item comes

00:09:06 ◼   ► after this one?" And then it fetches that and then it says, "What item comes after this

00:09:09 ◼   ► one?" And I need to now modify the API because the second item, the next next item, might

00:09:20 ◼   ► be the current item.

00:09:25 ◼   ► And people keep sending me, I have a couple of Twitter screenshots of like, so now it's

00:09:30 ◼   ► like, "Oh, I'm showing ATP and then next is showing this, but then after that it's showing

00:09:33 ◼   ► ATP again." Because it's like looping around because of the certain order of items. The

00:09:37 ◼   ► other thing is, if you're in a prioritized playlist and you go down and pick something

00:09:44 ◼   ► and you say play next, do I change the priorities of the playlist to make that work? Like, no,

00:09:52 ◼   ► that would be terrible, right? But then do I temporarily suspend play by priority? It

00:09:59 ◼   ► messes up everything. And so ultimately I think what I'm going to have to do is, I can

00:10:07 ◼   ► handle the widget, I can just make the API more complicated so it keeps track of like,

00:10:12 ◼   ► well if these two were already played, what's next? Which is annoying, but I can do that

00:10:17 ◼   ► fairly easily. But the play next functionality actually kind of doesn't make sense with play

00:10:25 ◼   ► next priority enabled. It kind of breaks in a lot of ways in a lot of conditions that

00:10:30 ◼   ► people might be using. So my inclination is just to disable play next completely if you

00:10:35 ◼   ► use that setting. Which most people don't, but the few passionate people do. Because

00:10:40 ◼   ► I can't think of a way to make that make sense. So it's like, all this complexity that I now

00:10:46 ◼   ► have to deal with because a year ago or whatever, I added this play next priority option because

00:10:51 ◼   ► I thought it wouldn't be that much work. I thought, oh, this is just really changing one

00:10:56 ◼   ► function. The function that says what comes next after this item. And I thought that would

00:10:59 ◼   ► be a really easy change that wouldn't affect a lot of things going forward and that would

00:11:03 ◼   ► be easy to support, but it turns out it really wasn't over time. So now I'm questioning whether

00:11:08 ◼   ► I should ever have added that option in the first place and it's causing lots of problems

00:11:11 ◼   ► because I did. So this kind of like, oh well, you know, it'll be easy. That often seems

00:11:19 ◼   ► true at first, but then down the road you see it wasn't easy to support this thing that

00:11:24 ◼   ► you thought was no big deal. Which brings you back to the original question of whether

00:11:28 ◼   ► you should have added it in the first place.

00:11:30 ◼   ► - Yeah, and I think too, it gets to this, it's this awkward balance you find too when

00:11:37 ◼   ► you add something. If you add a feature, taking it away is more--

00:11:43 ◼   ► - Unpopular.

00:11:44 ◼   ► - It's very unpopular, exactly. It is something that you will have a stronger reaction to,

00:11:50 ◼   ► I think, than never having implemented it in the first place. Because if that was an

00:11:54 ◼   ► important feature for somebody, if that was a vital thing that they were passionate about,

00:11:58 ◼   ► they absolutely need this feature and you don't have it, they'll just go somewhere else.

00:12:04 ◼   ► But if you give them a feature and it's this kind of this feature that's on the edge, it's

00:12:10 ◼   ► not an essential feature. It's not a core to your vision for the app. It's something

00:12:14 ◼   ► that you're adding because you think you should. And there might be some good reasons for that,

00:12:20 ◼   ► but in general, you're doing it because you think you should, not because you really want

00:12:23 ◼   ► to. At a certain point, you may have to take it away or scale it back or do things that

00:12:33 ◼   ► will ultimately be problematic for the application. And I think the examples you're giving are

00:12:37 ◼   ► very feature-driven, but at the same thing, I've been thinking a lot recently too about

00:12:42 ◼   ► what do you do with some of these iOS apps are getting so complicated in terms of the

00:12:47 ◼   ► number of possible extension points that we can add to them.

00:12:52 ◼   ► For example, iMessage apps is one that I've been thinking about recently where I have

00:12:58 ◼   ► never used an iMessage app personally other than to test the iMessage apps that I shipped

00:13:05 ◼   ► on day one of iOS 10. I've never used one in actual practice. I use iMessage all the

00:13:11 ◼   ► time. I use it to constantly text and interact with people, but I've never used an iMessage

00:13:18 ◼   ► app. And so I think about these apps that I added that I've never used them, and in

00:13:24 ◼   ► some ways, are other people using them? If they are, am I really serving their needs

00:13:29 ◼   ► or benefiting them? And at some point, part of me kind of almost wants to back them out

00:13:36 ◼   ► of the app, but doing that would be really awkward. Or similarly, you could have a similar

00:13:42 ◼   ► problem with things like supporting another platform, like the Apple Watch or the Apple

00:13:46 ◼   ► TV. I added a couple of my apps several years ago now where I added an Apple Watch app that

00:13:55 ◼   ► it turns out, for example, I added an Apple Watch app for my feed reading app, Feed Wrangler.

00:14:03 ◼   ► I don't think people use it very much, but it allowed you to read a plain text version

00:14:12 ◼   ► of each of your RSS items or something like that. I didn't know how people were going

00:14:17 ◼   ► to use Apple Watches. Maybe that would be kind of cool, but in actual practice, using

00:14:21 ◼   ► an Apple Watch, the last thing you really want to do is sit there with the crown scrolling

00:14:26 ◼   ► through a few thousand words of text. In retrospect, it doesn't make sense, but it's also kind

00:14:33 ◼   ► of this awkward position I find myself in now. That doesn't make sense. I had this

00:14:37 ◼   ► feature that I invented in this speculative way that I kind of want to take away, but

00:14:44 ◼   ► if there's a couple of people who are using it and find it really cool, that feels harsh.

00:14:49 ◼   ► So I think it is a good reminder for me to, in general, I need to be a bit more circumspect

00:14:56 ◼   ► with this. I need to think about these kind of features that if it isn't something that

00:15:01 ◼   ► I use myself, the best software I've ever written is the software that I use myself

00:15:08 ◼   ► on a daily basis. It comes from a place of actual need that I have, and then I'm solving

00:15:16 ◼   ► that need, and then I'm discovering that other customers also have that need. The degree

00:15:21 ◼   ► to which I can focus my development on those paths, on those behaviors, and on those features,

00:15:28 ◼   ► the quality of that software and that experience goes up. The degree to which I move away from

00:15:33 ◼   ► that and my apps start to become a bit speculative, and I'm just throwing things in and saying,

00:15:40 ◼   ► "Hey, what might work? What if someone did this? What if someone wanted to do that?"

00:15:45 ◼   ► And the more I do that, I think the worse my software becomes, probably, and the worse,

00:15:49 ◼   ► the more I regret it in the future when now I have to maintain all these features because

00:15:53 ◼   ► I feel bad about pulling them out.

00:15:55 ◼   ► Yeah, and I'll tell you one thing from experience recently. In Overcast 3, I also rewrote the

00:16:01 ◼   ► whole watch app to go from WatchKit 1, literally, to WatchOS 3, and in the process, I removed

00:16:07 ◼   ► a lot of features that nobody used. And I had analytics on that to see only something

00:16:12 ◼   ► like, I forget what the percentage, it was like a handful of percent points of people

00:16:16 ◼   ► use the watch app at all, and among those, it was like a handful of percentage points

00:16:22 ◼   ► of those used anything that was in the force touch menu. I had a few things in there. And

00:16:27 ◼   ► so I took it out because in the new version, I'm like, "You know, I'm rebooting the whole

00:16:30 ◼   ► thing from scratch. Do I really need to rebuild the screen that 3% of 3% of the users use?

00:16:37 ◼   ► Probably not, but that handful of users who use it, I've heard from all of them in the

00:16:42 ◼   ► meantime. They are very, very upset, and it does. It's like, I feel bad now. I feel like

00:16:48 ◼   ► I should add that back in, but that'll make the app a little bit bulkier and take more

00:16:53 ◼   ► time away from anything else. It's always tricky. Never add any features.

00:16:57 ◼   ► We are brought to you this week by Linode. Go to linode.com/radar. To learn more, sign

00:17:03 ◼   ► up and take advantage of a $20 promotional credit or use promo code radar2017 at checkout.

00:17:10 ◼   ► Linode gives you fast, powerful web hosting. You can set it up in just seconds, and they've

00:17:15 ◼   ► easy to understand tools to let you choose your resources and Linux distro, giving you

00:17:19 ◼   ► the power and flexibility that you need. Linode plans now start at just $5 a month for a Linux

00:17:25 ◼   ► server with one gig of RAM in the Linode cloud. That's an amazing price. Linode servers offer

00:17:30 ◼   ► industry-leading performance with native SSD storage, Intel E5 processors, and access to

00:17:36 ◼   ► a 40 gigabit network. I'll tell you what. These just sound like numbers. I've used a

00:17:41 ◼   ► lot of web hosts. One of the many reasons that Linode is my favorite web host is that

00:17:46 ◼   ► their networking is incredibly fast. The access that you have, especially inbound access,

00:17:52 ◼   ► it is incredible. My crawl servers that have a lot of inbound traffic and everything, it's

00:17:58 ◼   ► just crazy. Of course, outbound, they have tons of bandwidth there too. But inbound,

00:18:02 ◼   ► I believe you have higher limits. It's just as quickly as your server can accept data,

00:18:08 ◼   ► you can get it. It's amazing. They have an API. You can set up things quickly. You can

00:18:12 ◼   ► develop custom applications or automation, super simple scaling. You can scale things

00:18:16 ◼   ► in just a couple of clicks. I've done that a lot of times. It's wonderful. All Linode's

00:18:20 ◼   ► pricing tiers also feature hourly billing with a monthly cap on all plans so you know

00:18:24 ◼   ► what is the most you will spend in a month, and lots of other add-on services like backups,

00:18:28 ◼   ► node balancers. Linode's a great service. I highly suggest you check them out. I've

00:18:32 ◼   ► been running my stuff there for years now. I've been slowly moving everything that was

00:18:36 ◼   ► not on Linode onto Linode, and it's just wonderful. Highly recommended. Go to linode.com/radar.

00:18:44 ◼   ► To learn more, sign up and take advantage of a $20 credit or use the promo code radar2017

00:18:50 ◼   ► at checkout. Thank you very much to Linode for supporting this show.

00:18:54 ◼   ► So I think we've probably fairly effectively talked about some of the reasons why you probably

00:18:58 ◼   ► shouldn't add these kind of speculative features, these kind of things that are beyond the core

00:19:04 ◼   ► central vision you have for the app. But I think there are probably, it's worth doing

00:19:09 ◼   ► a little bit of the devil's advocate on the other side for some of the reasons why you

00:19:13 ◼   ► maybe might want to. And when I was thinking about this this morning, the main things that

00:19:19 ◼   ► came to mind for me is that, A, you expand the potential market for your application

00:19:27 ◼   ► to be larger than people who are just like you in terms of your preferences or the way

00:19:32 ◼   ► you think about this particular application or the way that you approach this particular

00:19:37 ◼   ► problem. And that's certainly better. Obviously it's great if the way that your vision for

00:19:41 ◼   ► the application is the same as it is for lots of people. That's great, but you can potentially

00:19:47 ◼   ► expand your market. If someone in your example of the "I like to be stressed" badge on my

00:19:55 ◼   ► overcast, if that was an essential feature and that was a thing that was keeping somebody

00:20:00 ◼   ► from using the app, and just adding it, like you said, isn't a huge thing, maybe it's worth

00:20:07 ◼   ► expanding that market that little bit. And even though that's a feature you would never

00:20:10 ◼   ► use yourself, you get that benefit of potentially expanding the market. Another example of something

00:20:16 ◼   ► that comes to mind is that you potentially are opening yourself up for other marketing

00:20:22 ◼   ► or promotion opportunities with Apple, especially around things like adding an iMessage app,

00:20:28 ◼   ► adding a watch app, adding an Apple TV app, adding an iPad app. The degree to which you

00:20:32 ◼   ► kind of embrace the new stuff can often have benefits, especially in that first wave of

00:20:40 ◼   ► things.

00:20:41 ◼   ► Although that's something to be a little careful of, though, because you make a watch app,

00:20:46 ◼   ► say, and Apple might feature you for a week, and then you're supporting a watch app for

00:20:50 ◼   ► the next three years.

00:20:52 ◼   ► Sure. And so there is definitely a balance to be struck there between over-weighting

00:21:00 ◼   ► the importance of that kind of marketing. But it is certainly something to keep in mind,

00:21:04 ◼   ► and it has a potential benefit. But I think I'm with you in that. Once I finished talking

00:21:08 ◼   ► about the benefits, I was going to talk about some of the costs. And I think one of the

00:21:11 ◼   ► biggest costs is overvaluing the potential upside, where because there is a definite

00:21:22 ◼   ► upside, it's easy to be like, "Oh, I should definitely do it. Doing this will make the

00:21:26 ◼   ► app better." Or maybe, "I will get this attention." Even if you know for sure that you're going

00:21:31 ◼   ► to be featured in the App Store, you have some great confidence, or you've been in contact

00:21:37 ◼   ► with someone at Apple, or whatever it is. Even if you're absolutely certain, the awkward

00:21:41 ◼   ► thing that you might run into is, like you said, you get featured for a week, but then

00:21:47 ◼   ► you support it for years. And that's a tricky balance.

00:21:53 ◼   ► And then the last benefit that I could think of was just in terms of reducing your support

00:21:57 ◼   ► requests. By the nature of a lot of these kind of features, there are things that people

00:22:01 ◼   ► keep asking for. And so there is always going to be a certain weight on your support load

00:22:08 ◼   ► of people asking for this. And until you add it, that will be the case. But in aggregate,

00:22:16 ◼   ► I think as I've developed apps and had to support them for longer and longer, I think

00:22:21 ◼   ► this is something where I'm starting to develop a bit of an immunity or resistance to these

00:22:30 ◼   ► types of features. And I think in general, it's something that I'm going to be trying

00:22:34 ◼   ► to resist as much as I can. It is crazy with this particular app that I'm working on,

00:22:40 ◼   ► Audiobooks, because it's eight years old. And we talked about in our episode about dealing

00:22:43 ◼   ► with old code, there's all kinds of technical challenges. But there's also a lot of feature

00:22:49 ◼   ► load, and features that I added years ago that I'm now still having to deal with and

00:22:56 ◼   ► maintain. And I think there's a lesson to be found in, especially as an independent

00:23:03 ◼   ► developer, as a smaller developer, that I think we're typically best served when we're

00:23:09 ◼   ► able to focus down to the things that we really enjoy. Because guessing at solutions are never

00:23:17 ◼   ► going to be as good as actual solutions. Like guessing how someone might want to use this

00:23:23 ◼   ► feature based on the email you got, someone asking for it, is never going to be as useful

00:23:27 ◼   ► as the feature that you build because you love this thing, and it's what motivated you

00:23:32 ◼   ► to build the app in the first place. And I think, at least I find for myself, that motivation

00:23:38 ◼   ► is a very important thing. I'm doing this update to Audiobooks mostly because I feel

00:23:42 ◼   ► like I have to, because I haven't done one in about a year, and that's not good. And

00:23:47 ◼   ► a big part of why I think I am resistant to getting into this codebase, and why it took

00:23:52 ◼   ► a lot of girding my loins and "Let's do this" to do, is because the app had gotten

00:24:00 ◼   ► so divergent and had all these little extension points and differences between things that

00:24:06 ◼   ► made it more intimidating and it made it less fun. And as much as I do my job because it's

00:24:13 ◼   ► my job, because I'm independent, I have the flexibility to just kind of benignly let

00:24:20 ◼   ► things be neglected for longer and longer. There's no boss yelling at me in quite the

00:24:24 ◼   ► same way. And the product suffers as a result. And I think ultimately the products will be

00:24:31 ◼   ► better the more that I think it's fun to work on them. And so this is one area where

00:24:37 ◼   ► I'm starting to think, "You know what? I need to scale that back." And in this case,

00:24:40 ◼   ► it meant that I'm going to take the iPad version and make it very, very similar to

00:24:46 ◼   ► the iPhone version. And other than a few places where there's popovers rather than modal popups,

00:24:52 ◼   ► the apps are now identical. And I feel so much better about that. I feel so much...

00:24:57 ◼   ► It's like this great relief is off my shoulders because I'm not building this app that I'm

00:25:01 ◼   ► just guessing at. I'm just building an app that I know works really well, and is now

00:25:05 ◼   ► slightly worse for some of the users. But I think overall, they'll be a lot happier

00:25:10 ◼   ► with the fact that the app is going to be updated on a regular basis because I think

00:25:14 ◼   ► it's fun now. Because it's interesting, and I'm actually tackling interesting problems

00:25:18 ◼   ► that I've wanted to tackle for a while, but I didn't feel like I could because I had

00:25:22 ◼   ► all this other baggage and all this other load that I had to deal with as well.

00:25:26 ◼   ► - Yeah, I mean, I think as indies we have to always be conscientious of our limits,

00:25:35 ◼   ► as individuals or as very, very small teams. I think we have to recognize we can't do

00:25:41 ◼   ► everything. We won't want to do everything. So both in capacity, we don't have the bandwidth

00:25:51 ◼   ► to actively maintain and update and build lots of features and stuff that we don't

00:25:57 ◼   ► want to build or that we won't use, or that we won't be able to test necessarily. In

00:26:04 ◼   ► our informal testing protocols, this is why we should have unit tests, but we don't.

00:26:08 ◼   ► Also, if it's not something that we're going to use ever, a lot of untested bugs

00:26:13 ◼   ► could slip through, like in my Play Next by Priority thing where basically I don't think

00:26:19 ◼   ► any of my beta testers use that option. I don't use it, and so all these bugs slip

00:26:23 ◼   ► through into 3.0 features that I just never even considered because I don't use a feature.

00:26:28 ◼   ► It's kind of this edge case thing that I didn't think would interfere with anything,

00:26:31 ◼   ► but it does. So part of being an indie is having to step back and say, "You know what?

00:26:36 ◼   ► I can't do a whole kitchen sink set of features here. I just can't do that," and

00:26:41 ◼   ► maintain it to a decent level of quality. So you kind of have to just do what you think

00:26:47 ◼   ► is best for the app and what you can manage and what you can maintain over time responsibly.

00:26:53 ◼   ► And then secondly, part of the advantage of being an indie is as long as the business

00:26:59 ◼   ► is doing okay, you can choose. As you said, there's no boss. You can choose what to

00:27:05 ◼   ► work on. It's your app. You can choose what features it has. You're never going

00:27:10 ◼   ► to get everybody to use your app, so as long as you can get enough people to keep yourself

00:27:14 ◼   ► in business, then you can make the app you want and you don't have to listen to everybody's

00:27:20 ◼   ► requests. And that's something that I have been telling myself a lot recently as I deal

00:27:25 ◼   ► with bugs with options I never use.

00:27:27 ◼   ► Yeah, and honestly, it's a relief. It's a weird thing, and I think I talked to you

00:27:35 ◼   ► about it. I remember when I first had this realization that I was going to just drop

00:27:39 ◼   ► the iPad version that I had built and just switch to it being based on the iPhone layout

00:27:44 ◼   ► and flow. I was genuinely happy and relieved, and it felt good in a way that a lot of decisions

00:27:52 ◼   ► don't give you those feelings. But it was a great encouragement to me that I was excited

00:28:00 ◼   ► about working on this app in a way that I hadn't been before because of this choice

00:28:04 ◼   ► that I'd made. It's kind of fun to feel empowered to do that. I didn't have to go

00:28:12 ◼   ► before a committee. I didn't have to convince anybody else of doing that. I decided that

00:28:16 ◼   ► this would be better for me and, as a result, better for the app, and just went with it.

00:28:24 ◼   ► That is one of the rare gifts we get by being our own boss, and it is something that I think

00:28:31 ◼   ► is important to take advantage of. A lot of being independent is rough, but this is one

00:28:36 ◼   ► area where if you find an opportunity to do something that you think will make you enjoy

00:28:41 ◼   ► working on the app more and will avoid these kind of headaches where you feel like, "Why

00:28:46 ◼   ► am I even building this? I don't like this feature in the first place." That's a great

00:28:50 ◼   ► opportunity to say, "You know what? I'm not going to. I'm going to take this feature

00:28:55 ◼   ► out or I'm going to change this in a way that I think will make me more excited to

00:28:59 ◼   ► work on the app." There's nothing more soul-crushing than working on a bug that you don't even

00:29:03 ◼   ► want the feature to exist in the first place. Embracing it can be a really powerful thing

00:29:12 ◼   ► to motivate you to do better work, and any opportunity we have to do that is definitely

00:29:16 ◼   ► worthwhile.

00:29:17 ◼   ► >> WESLEY CHUNG: And with that, we're out of time. Thanks, everybody, for listening,

00:29:20 ◼   ► and we'll talk to you next week.

00:29:21 ◼   ► >> DERK WALKER-GRIEGER. Bye.