RWDevCon 2017 Inspiration Talk: Silver Bullets and Hype by Roy Marmelstein

Implementing the Trend

Okay, it’s story time:

After attending my first conference, there were so many exciting ideas. There was this one live-coding talk, which is a bit like a tutorial but less interactive, so you just watch someone do the work.

What they did is just subtract away all the boiler plate that goes around writing a table view with adapters and with protocols and ended up with a very small bit of code to change the contents of the table view. I thought this was brilliant, I was so excited about it.

I came back to work on Monday and I really wanted to implement this. At that time, we were working on a new view controller with a complex collection view, complex layout with updating logic. I thought, “Yeah, let’s do this”.

On the surface, this was quite a successful experiment. We we’re able to copy that approach very quickly, ended up with very short code and it was really good … but flaws revealed themselves over time.

When new people joined the company, no one really wanted to touch this class because they had no idea what was going on there. I couldn’t give them a good reason for why it did this apart from the fact that it’s cool. That became a bit of a problem. And I noticed was that the collection view was not reusable. I wasn’t trying to get composition and reusability out of it; I was just using it because I wanted to.

This is something I noticed that a lot of people do with protocol: just using it to represent data that, again, you don’t want to compose or reuse, and this doesn’t give you that much over just using normal value types.

Lessons

The blue-background images will be technical learnings about the technologies, and then there’s a green screen afterwards about learnings in general.

The technical lesson here is that protocol-oriented programming is fantastic for composable, reusable behavior and not so fantastic for describing data and doing things that you don’t want to compose and reuse.

The big learning in general here is that you should really start simple.

Don’t approach a problem because you have this new technology that you’re excited about, but actually try and solve it in the most simple way and then see if there’s actually a need for this. Really consider what you get out of using a technology; just the fact that it’s cool is not really a valid justification for using something.

Functional Reactive Programming

The second thing I want to talk about is functional reactive programming.

We have two very popular frameworks: RX Swift and Reactive Cocoa. The buzz word here is that it’s declarative and everything is a stream.

The dream that is sold to developers is that your app will just become a function of state. Again, this is something that’s very seductive, we like to look at our apps and it’s this complex set of cogs and machines moving each other and the idea of an app is just a river of operations and chains. It’s something that’s quite nice and you think you’ll have a less buggy app if you do this.

When it works, it works quite well. Again, you don’t really need to look at this code, but doing e-mail validation with about two lines of code is something that will take a lot more to do in Swift, and so RX Swift can be quite nice.

Another one of the selling points is that RX Swift is part of a family of RX frameworks; you have RX Java as well, and in theory, you could do the same kind of manipulations of events on Android and get some kind of a cross-platform benefit.

Again, this is not really a silver bullet.

More Story Time

Another story: in the previous company, a CTO got super excited about RX and we had the problem where we had an Android app and it was hard to keep both apps on par and having the same behavior. And we had a few bugs that were very hard to replicate.

The idea was that we would rewrite both apps and try to use RX pretty much from the data layer all the way to the UI and get something good out of that. Through the experience, you realize that there’s quite a steep learning curve to using RX.

The basic concepts are easy to understand, but it takes time to really get good at it. Generally, talking to other developers, I think the consensus that it takes months until you start to think of problems as RX problems and problems of streams and events. There are about 25,000 results for functional programming on Amazon.

A lot of people find this quite difficult, I guess. Then, once you do master it, you end up with code like this.

Again, what you need to see here is that it’s quite complicated to read.

It’s not only that you need to learn it and your team needs to learn it but everyone who will join your team will need to take this time to understand RX and will take time before they become useful members of your team.

Another issue we had was with UIKit.

UIKit is not really on board with this vision of declarative interface. RX has some tools: we have RX Cocoa and RX Status Source and they try to massage it into being declarative. But every once in a while, UIKit will have its little revenge.

Generally, if you’re doing complex things with UI, it can become quite difficult and UIKit is a big source of pain.

If you’ve ever used KVO, you’ll know this problem where you have these streams in your app and if you get a crash report, it’s really hard to see what actually happened and it’s really hard to debug.

With RX it’s like that on steroids. This image is rendered by a tool for RX Java but I think it’s like a calculator app and it’s just showing you all of the streams that are happening.

Even though there are tools for helping with that journey development, again, if you get stack traces from people out in the wild, it’s really hard to see what’s going on. Basically, for that experience, the result was that it was really hard. We didn’t get the parity with Android, that didn’t happen. We ended up with more bugs that were quite hard to debug and we had to do a bit of refactoring, scale back the level of RX usage in the app and stop slightly further down the stack.

It was a great learning experience but it wasn’t a great experience from the product perspective and from the development perspective.