RWDevCon 2017 Inspiration Talk: Silver Bullets and Hype by Roy Marmelstein
As developers, we often search for a “silver bullet” that will solve all of our problems. In this talk, learn how to better evaluate & make tech choices. By Roy Marmelstein.
We recorded these talks so that you can enjoy them even if you didn’t get to attend the conference. Here’s one of the inspiration talks from RWDevCon 2017: “Silver Bullets and Hype” by Roy Marmelstein. I hope you enjoy it!
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.
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.