Josiah Renaudin: Welcome back to another TechWell interview. Today I am joined by Ellen Shapiro, the director of iOS engineering at Vokal and a keynote speaker at our upcoming Mobile Dev + Test Conference. Ellen, thank you very much for joining us today.

Ellen Shapiro: Thank you for having me.

Josiah Renaudin: Absolutely. First, before we dig into the meat of the presentation, could you tell us just a bit about your experience in the industry?

Ellen Shapiro: I am someone who has mostly worked in agencies. I actually don't have a background in computer science. My undergraduate degree is in radio, television, and film production.

Josiah Renaudin: Oh, wow.

Ellen Shapiro: I worked out in Hollywood for a few years before I got a little bit tired of that. I decided to do something completely different, so I went through some very basic programming stuff and then just started building stuff. Finally built enough stuff to convince a place called The Nerdery here—they're based in Minneapolis, but I worked at their office here in Chicago—to hire me and bring me back to the wonderful frozen tundra that is Chicago. I worked there for a couple of years and then I moved over to Vokal at the end of 2013, yeah.

It's been fun. Both The Nerdery and Vokal are agency-model places where you have a lot of different projects. You have a lot of different people working on projects and you get to see a lot of different ways that things can be done. It's been really, really interesting for me to see that, see a lot of what to do and a lot of what not to do.

Josiah Renaudin: Hopefully you're not having as awful weather as the East Coast in Chicago right now.

Ellen Shapiro: Oh, no. I grew up in Washington, D.C., and I feel for my mom. She's still there; I called her and she was like, "I can't even see the building next door to me." They're digging out, but it will be ... Here it's just kind of cold.

Josiah Renaudin: All my family is in Pittsburgh, so I'm just like, "I'm in Jacksonville and I feel almost guilty for being here when it's 60 degrees right now."

You know what? I made the right decision.

Ellen Shapiro: I was going to say, I think this is probably validating your decision.

Josiah Renaudin: Your keynote, which is titled “Balancing New Tools and Technologies Versus Risk,” really dives into how to evaluate new tools for benefits and possible hazards. First off, do you often find teams, and even yourself, overwhelmed by the sheer number of new programs, tools, and technologies that are constantly flooding the market?

Ellen Shapiro: Yeah, absolutely. I mean, I think it's something where, I think it's not just overwhelmed, but also super excited by it. Programmers by their nature are always interested in “Is there a better way to slice this bread?” These new tools and technologies, a lot of them have this promise that, "Hey, we're going to actually do a thing that's been difficult and make your job easier." That's something that's real tempting to a lot of engineers. It's something where trying to weigh the promise of what these new opportunities are promising versus the risks of moving to these new technologies is always a real difficult thing to do. I'll be talking a little bit about my experience in doing that; in particular I'm going to be talking about switching from Objective C primarily to moving into Swift.

I'm also going to talk a little bit about, our Android team has actually dove into a language called Kotlin—pretty hardcore—which runs on Android and offers a lot of the same sort of promises as Swift in terms of potentially being able to reduce errors. I'm going to do a little talking about that, what's gone well and what has not gone well with that.

Josiah Renaudin: You mentioned Swift, and there are a lot of companies that maybe rightly go with the safer, manufacturer-built, supported languages like Swift. What are the benefits of riding the bleeding edge, going for the cutting edge, different languages and projects that might not be nearly as widespread and widely used?

Ellen Shapiro: I think it really varies from project to project and tool to tool. I think there's definitely some software with the advantage of being able to do something much more easily in theory. If the documentation's not there, if the community support isn't there, it actually does not wind up being quite as simple as it says on the tin. That's something where evaluating ... OK, in theory, how much easier can this make my life? Versus in practice, how much harder is this going to make my life?

It’s always a real battle when you're trying to figure out, OK, where do we decide that enough people are using this that we can take a risk on it? I think there's certain things where the difference that you see, in terms of how much easier this thing could potentially make your life versus the risk of continuing to use the same thing that you're doing that's making you tear your hair out, is so big that it's like, well, we might as well take a shot at this.

It's definitely something where it can be really, really something that you have to look at very much on a case-by-case basis. I think one of the things I'm going to be talking about is some of the criteria that we use to weigh when it's something that our engineers are going, “Whoa, shiny” about, something that we actually want to try to put into production, versus when is it something where we want to spend a little bit more time prototyping with it, we want to spend a little bit more time poking at it. Either as a smaller piece of a larger project or as just a little standalone project in order to be able to move forward with it in a way that has less risk. I think for us as an agency, there's always a risk where we have budgets we have to stick to, we have timelines we have to stick to. Those are really huge things for us in our industry.

Obviously, anybody who is working directly for a company has budgets and timelines, but there's not quite a direct consequence of going over them as you tend to see in the agency world, which is you lose clients if you do that on a regular basis. It can really cripple your business if you're moving too quickly to get way the hell out in front of everything.

Josiah Renaudin: It seems like so much of this, the smart answer is always to look at everything case by case. You don't want to have this broad, general idea that works for everything, because it's usually not going to work for everything. What's the most common first step Vokal takes when approaching a new tool? How does this evaluation process for specific companies often start?

Ellen Shapiro: I think a lot of the time, one of the things that we ... One of the first things we look at is, what problem does this actually solve? There's plenty of stuff where it's like, oh, yeah, this is going to make your JavaScript 30 percent faster, or something like that. It's like, well, JavaScript is already pretty fast. How much of a benefit is that versus whatever else is going to be happening? It's something where you start by looking at what is the actual problem domain here. How much time are we actually spending on this problem domain? Are we reinventing a wheel that's already pretty solid? Or is it something where this is an area where there's been a lot of problems in the past? I think a particular example of this on our Android side was looking at Realm, which is a database replacement.

One of the things that we had seen on the Android side was that there really aren't a ton of really great, well-written database layers for Android. Realm takes a bunch of stuff into account that a lot of other database stuff really doesn't. On Android it made a lot more sense for us to start with that a lot earlier. Whereas on iOS, iOS has had Core Data, which is this model object layer over databases for quite some time. It's considerably more robust. We have this whole fleet of tools that we built out to help us deal with its sharp corners and all that kind of stuff. It's something where we're not moving into it as quickly on iOS because the set of tools that we already have is pretty strong.

It's something where, in that case, Realm has been picking up pretty solid momentum on both platforms. We're looking not just at, OK, is this a good solution that can work across both platforms, but is this the right solution for each platform? We're making decisions based on that.

Josiah Renaudin: Sticking in this evaluation stage, how do you know when to simply select specific pieces of your app to move over to a new technology versus taking that chance, taking that risk, and going all in?

Ellen Shapiro: Some of it is about whether we're working with an app that already has an existing code base. It's one of those things where you don't want to fix what isn't broke. It's something where if you already have a fairly strong code base in one language, that's where you can get a really good opportunity to say, "OK, we have this really strong code base in this language. We're going to start working to either transition new pieces of it into this new language, or we can start ..." There was a really great talk at the 360iDev Conference this year from a team where they basically decided to change each vertical of the application. If you're actually looking at the app, you can think of it as one tab, two tab, three tab, four tab. They started with the first tab and they changed everything from the data layer all the way down to the networking layer over to Swift.

Then they moved over to the next tab, because once you change one thing, it makes it a little bit hard to take advantage of all of the features of the language if the whole stack isn't there. It's also something where you don't want to just throw the baby out with the bathwater.

Josiah Renaudin: This is, of course, another pretty broad question, but I think it's something that people would be interested in who attend your keynote. What are some of the biggest mistakes that you've seen throughout your time at Vokal, or even another company, that you really feel like you could help people avoid when they're going through this process?

Ellen Shapiro: I think one of the biggest things—and this is sort of what I'm talking about with finding these criteria—is not actually having any criteria. When do we want to plow ahead with this new technology versus when is that probably going to be too much risk for what we're trying to do? There's definitely been a level of YOLO that can happen with that. It makes it get to a point where you can make some decisions, where you can back yourself into a corner and you have to get out of it. That can take a lot of time. I think it's also something where one of the things that I've seen be very helpful is, OK, if you're trying something that's new from a technological standpoint, you may want to try it on something that's not exactly reinventing the wheel on the app standpoint.

One of the things, again, that our Android team was able to do was work with a particular application that had eight billion forms that people had to fill out for credit cards, addresses, and all that kind of stuff. Really see how reactive programming had worked for them in that way, and it was something where the app itself really wasn't all that complex. It was something where they were able to validate that these techniques worked. The next time that something else came up the pipe, they were able to move into using these techniques that they'd refined and shown to the rest of the team on this newer app that's a little bit more challenging.

Josiah Renaudin: This is now officially my favorite interview because you used "YOLO" directly in an answer, and that's something I've been doing too, so I'm glad I'm not the only one. Ellen, thank you very much for speaking with us today. I appreciate all the insight and I'm looking forward to hearing more from your keynote at Mobile Dev + Test.

Ellen Shapiro: All right, great, thank you so much.

Ellen Shapiro is the Director of iOS Engineering at Chicago-based agency Vokal, which helps companies develop and build their vision for taking advantage of a mobile world. When not working, Ellen partners with designer and fellow singer-songwriter Aaron Shekey of Github to create the leading songwriting app Hum. Ellen also writes tutorials for leading iOS tutorial site RayWenderlich.com and will talk your virtual ear off on Twitter as @DesignatedNerd.