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

Transcript

Today we’ll be talking about silver bullets … like this one:

The idea of the silver bullet has its origins in horror movies and horror literature; it’s the one tool that can kill all of the monsters. It can kill the werewolves and the vampires.

When we talk about silver bullets in programming, we’re talking about the same kind of idea. Basically, it’s the quest to find a tool that can make our code better and bug-free and easy to maintain. I think this is something that we all do at some point in our career.

The story should be familiar to most of you. You go online, you read a blog post that really inspires you, or you attend a conference that’s really cool and you go to all of these tutorials. Maybe one idea really grabs you and you get super excited.

via GIPHY

And on Monday you go back to your office, you talk to your team, you open up X-code and the first thing you want to do is implement this exciting new idea.

And you do that, and over time you start realizing that maybe the idea was not the perfect solution for your app, and that your app has some special needs and special constraints.

As time passes, basically you just create a technical debt for yourself. This ends in tears and you need to reflect and refactor. Basically, this keeps happening and I think it happens to senior developers and junior developers alike, so it’s not really a question of experience and I kept wondering why.

Why Do We Seek Out Silver Bullets?

The answer I came up with is that it’s about hype.

We got into programming because we love technology, we want to make things and we want to live in the future, so it’s natural that we get excited by new solutions.

When I’m talking about hype, I’m also talking about a trademarked idea of hype.

Gothno, which is a research firm, has this Hype curve, which looks like this:

It’s used for investors to assess the life cycle of technology adoption. All technologies start with a trigger, they reach a peak of inflated expectations, a trough of disillusionment and eventually a plateau of productivity. These are all great titles for them.

If you think about desktop computing, that’s somewhere deep in the plateau of productivity; with self-driving cars, we’re in the peak of inflated expectations.

I think this really applies to iOS technologies and frameworks and ideas as well. Basically, the point of this talk is trying to understand through experience and through shared stories how we can accelerate getting to that plateau of productivity because that journey is quite painful and expensive.

I’m going to talk about three trendy ideas in Swift. I will explain a bit about what they are, though I know you’ve had a busy two days, so I’ll keep it very brief. Then I’ll try and see what we can learn from them.

Protocol-Oriented Programming

First up, we’re going to talk about protocol-oriented programming. In the past year I’ve attended a lot of conferences around Europe. Pretty much every one of them had a talk about protocol-oriented programming.

The buzz words when we talk about these are composition over inheritance.

As someone who grew up playing Legos, composition is something that we like, and the idea that we can build our classes by just putting things together is cool as a developer.

It got popular after this talk at WWC in 2015 where we met Crusty.

Apple really sold it as something that will really change the way we write code forever; it’s a great new paradigm for writing Swift code.

It’s often explained with cars, but I wanted to do a quick RW Devcon explanation, so I’ll explain it with tutorials.

You don’t need to look very deeply into this code, but if we wanted to do the object-oriented presentation of a tutorial, we can have a tutorial class with a couple of tutorial functions like writing and presenting and publishing. We have all the talks that we’ve had in this conference, like Mastering Git, and all the sub-classing, and the big tutorial superclass.

The problem arises when you have books and we just want to pick the right function from the tutorial. Basically, object-oriented programming gets very monolithic, and it’s very hard to pick and mix functions and use them as we want.

The big idea of protocol-oriented programming is that we just can break this down into protocols.

With Swift, we can have default implementations of things and then we just describe the tutorials as something that’s writable or publishable and presentable.

Then we can present books very easily, something that’s writable, an inspiration talk is something that’s presentable, we can even mock things up in a really nice way. This is super cool and it’s very useful but … it’s not a silver bullet.

Why? I think basically it comes down to this idea that if you have a hammer, everything looks like a nail.

Especially if it’s a hammer that you really enjoy using, you just want to use it again and again. I think we just went a bit overboard with this as a community.

You’ll see a lot of popular blog posts saying that if you’re sub-classing you’re doing it wrong. On Github, if you search for “protocol-oriented”, there are almost 180 repositories and that this is one of their selling points in Swift that it’s protocol-oriented.

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.

Lessons

My learnings here were that RX is really good for simplifying data flows, but if you have a lot of complexity in your app, especially in UI and you expect to onboard a lot of new people, it could become an issue.

The general lesson here is that, even if you’re in a position to do it, you should not force new technologies on your teams, especially not with a broad mission like rewriting the entire app.

Again, most things are not silver bullets, they have limitations; in order to discover the limitations, it’s better to start with smaller tasks.

I think it’s really important to consider the future debt. I have a friend who worked on an app that went all-in on Reactive Cocoa and then changed their minds; it took them the best part of a year to remove Reactive Cocoa. So really try to consider if that’s something you’re willing to do before choosing to adopt a new technology.

Swift

The last thing that I want to talk about, which I guess is controversial for this kind of talk, is Swift itself.

Everyone loves Swift, I love Swift. It was sold to us as Objective-C without the C, which is pretty cool.

These are just a few of the things that I love about Swift; we have protocols and syntax and type safety, value types, it’s functional-ish. It’s a great language, it’s really fun to write, but I don’t think Swift is a silver bullet. I think it depends on your needs and the app that you’re working on.

Even in 2017, I don’t think every app needs to be written in Swift, and Objective-C still has a place.

Story Time: My Swift Experience

I have quite a few Swift frameworks, and I got to work on two apps that use a lot of Swift, both full Swift and transitioning from Objective-C to Swift. I encountered a lot of issues in that process.

The main one was compile times:

This dictionary could take eight hours to compile. Type inference is a big problem in Swift. You won’t really get this in your real app, but the worst it got for us was it took about eight minutes to compile the app. It really kills motivation when every time you run it you have to go and make some coffee. That was a big problem for us.

Another issue is basically having to do this ceremony each year where you have to convert your app every time there’s a new version of Swift. It’s nice that we have a converter, but it’s really not perfect. For me, the big issue is that the unit test broke as well. You can’t just trust that it works.

Talking to other developers, on average it seems to take about two to three weeks to update. If you can’t really afford to do that, maybe that’s something that you should consider.

The last issue is modularity, so if you’re working on an app with a lot of other people, it’s nice to keep things modular and break things into framework. I think there was a workshop about that as well. In Swift, that’s a bit difficult because we don’t have static libraries so everything needs to be dynamically linked.

Apple says we should have a maximum of six, which is not very realistic. What you end up with is quite significant launch times and that could be a problem as well.

Lessons

My experience was that for new projects, especially for open source Swift, it’s amazing. It’s great to learn Swift and it’s really fun.

I think it’s important to learn Swift now because you can influence the development and influence the future of iOS and the server, but consider the constraints of your project.

If you have a project with a lot of legacy code and a lot of contributors and dependencies, I would personally hold back with Swift right now.

The wider learning is to fully consider the constraints of your projects, even if it goes against the common beliefs in the industry right now.

Wrapping Up

The message of this talk is not that you should not try new things, and I think that should be quite explicit. We’re actually very fortunate to work in an industry where we get all these new ideas and we have all these new technologies coming in to solve our problems. We should stay excited and we should try them, but the message is more that:

• We shouldn’t follow trends just because they’re trends.
• We should not approach a new technology as a potential silver bullet.
• We should know that all technologies have limitations.
• We should try to figure out these limitations as quickly as possible and to focus on solving the specific problem in the app.

I know this is quite easy to say but quite hard to do, so I have some suggestions about how to do that.

I think, generally, hackdays and hackathons and side projects are great ways to experiment without the depth of doing it in your main app.

For me, though, the real solution is more of these story times. As a community, we’re very good at sharing excitement about new things and sharing success stories, but we’re not so good about sharing lessons from mistakes and sharing limitations of things. We need to get better at that, because we get excited about the same things and the more we learn from each other, the shorter that time to the plateau of productivity is.

I want to end on a really positive note and keep the excitement going: we should still stay excited about things and stay hungry and stay foolish.

Just try to have a slightly more critical appreciation of things as you’re excited about them. Thank you!