Unpacking Technical Decisions - NDC London 2014

•Unpacking • Technical • Decisions • Sarah Mei • @sarahmei
! • Chief Consultant • @devmyndsoftware Hello! I am Sarah Mei — @sarahmei most places on the internet. I’m the Chief Consultant at DevMynd Software. ! Many thanks to Jakob & Charlotte & the rest of the NDC team, for making it possible for me to do this talk at NDC London in December 2014. ! London was nice. I’m not from there, though. !

I’m from San Francisco. This is the beach near my
apartment. Over there on the right side is that one bridge everybody can identify. ! On the left side is my 6-year-old son enthusiastically digging a hole in the sand, even though it’s 40 degrees out. Uh, which is like…7 celsius, I think, for you guys? Meanwhile I was taking this picture in a parka & a scarf. ! So San Francisco looks like California, but has London- esque weather. :)

of DevMynd, where I work, is a consulting company. I
work with some fantastic people there. ! I’ve also worked with other fantastic people in the past.

of In addition to my client work, DevMynd supports my
community work, which is awesome. ! I am a director of RubyCentral, the nonproﬁt that runs the two largest Ruby conferences in the world: RubyConf & RailsConf. I’m in charge of the technical program for RailsConf. Our CFP is opening soon, and I would love to see you send in a talk. ! I founded & am on the board of RailsBridge, a movement working to get more diversity into our community.

of So I do a lot of different things. You
can probably tell that I do a lot of Ruby. :) ! I worked for Microsoft in the late 90s, then switched to Java, for a while, then in 2006 started using Ruby. That’s also when I started seriously working with JavaScript.

DevMynd + These days my client work is pretty much
50-50 Ruby- JavaScript. I think a lot about how teams can sustain, refactor, and evolve large codebases over time, so that they stay easy to work with as they age. ! It’s been super interesting at this conference to discover that .NET projects, despite being written in a strongly- typed language, have many of the same problems that Ruby & JavaScript projects do, including that as a project ages, it seems to get harder & harder to work with.

DevMynd + In my consulting work I’ve been on dozens
of different teams, worked with hundreds of different developers, and helped them make decisions — large and small — about their code. ! This talk is what I’ve learned about how we make decisions about code, how we can get better at that kind of decision-making, and ultimately, how we can move towards codebases that are better equipped to go the distance.

It’s a technical talk — there is code. It’s in
Ruby, but don’t worry if you haven’t seen Ruby before. I’ll walk you through what’s going on, and the focus is on the concepts, rather than on the speciﬁc implementation.

This talk is equally about people, though. As developers, we
often think of code & people as completely separate topics. For example, a technical conference is said to have “hard” talks that are about code, and “soft” talks that are about people. ! That naming has always been a bit perplexing to me, because soft talks are anything but easy. In fact, they deal with the hardest problems we have: human relationships.

DevMynd Programming is easy. It’s being a programmer that’s hard.
@JEG2 I loved how James Edward Gray II put it in 2013: “Programming is easy. It’s being a programmer that’s hard.” ! He didn’t mean that programming itself is easy to learn, or easy to do. He meant that once we’ve ﬁgured out how to make computers do what we want, we discover that that was the easy part.

DevMynd Programming is easy. It’s being a programmer that’s hard.
@JEG2 Making great software involves getting people to do what we want, too, and people are way harder for most of us to ﬁgure out than computers.

DevMynd INSEPERABLE This is my favorite Venn diagram. There’s no
way you can have one of these musicians without having all three. ! And it’s the same with people & code. We think they can be analyzed independently, but they really can’t.

DevMynd Any organization that designs a system will inevitably produce
a design whose structure is a copy of the organization's communication structure. CONWAY’S LAW Melvin Conway This is true at the structural level, due to a principle called Conway’s Law, which was formulated in 1968. Here’s what it says. ! It’s a bit of a mouthful. I kind of like how Eric Raymond restated it -

DevMynd If you have four groups working on a compiler,
you’ll get a four- pass compiler. RESTATEMENT Eric Raymond What this means is that you cannot separate the structure of your people from the structure of your code. ! Wherever you have a team boundary, you will also have a code boundary.

DevMynd INSEPERABLE But you can’t separate people from their code
at a smaller scale, either. ! I can tell a lot about programmers by looking at the code they write. I can see how much schedule pressure they had. I can tell how clear — or not — the requirements were that were driving the code. I can often tell what their technical background was.

DevMynd INSEPERABLE People & code are inextricably linked, and we
do ourselves no favors when we try to separate them. ! This talk deals with what is perhaps one of the most explicit overlaps of people & code: technical decision making. How do people make decisions about code? ! It was inspired by my experience earlier this year at the Fluent conference. Fluent is O’Reilly’s big front-end conference, covering HTML5, JavaScript, CSS, & all that stuff.

•People at Fluent http://www.ﬂickr.com/photos/oreillyconf/8893292969 Here’s an official picture from Fluent.
As JavaScript conferences go, it’s big - several thousand people - and also conservative. ! It was really interesting to talk to the people there, because it felt like a more realistic cross-section of JavaScript devs than I meet at the smaller conferences. ! The smaller confs draw the fanatics. Many of the folks at Fluent work at large companies. This is their one conference for the year.

•People at Fluent http://www.ﬂickr.com/photos/oreillyconf/8893292969 So while I was there, I
spent a lot of time in the hallways talking to people about who they were and why they were there. ! I met three categories of people:

DevMynd AT FLUENT: •Back-end developers •Visual & interaction designers •Front
end developers Back-end devs, looking to learn more about front-end development. ! Visual and UX designers looking to learn about front-end from the other direction. ! But the largest group of people I talked to, unsurprisingly, were already front-end devs. They were there to stay up to date & learn about new techniques.

DevMynd AT FLUENT: •Back-end developers •Visual & interaction designers •Front
end developers These are three groups of people with very different past experiences. So, it really surprised me to ﬁnd that when I asked about speciﬁcally what they wanted to learn, they all told me the same thing. ! Here are some quotes. See if any of them sound familiar.

DevMynd “My group has started an ember project, so I’m
going to every ember.js talk on the schedule.” “My group has started an Ember project, so I’m going to every Ember.js talk on the schedule.” ! Fluent was multi-track, and it was pretty easy to construct an Ember-only schedule.

DevMynd “My web app has an old jQuery codebase and
I need to ﬁgure out what to do with it.” “My web app has an old jQuery codebase and I need to ﬁgure out what to do with it.” ! This person said the word “jQuery” in a tone dripping with contempt. One thing I learned at Fluent is that some people have a deep and abiding hatred for jQuery.

DevMynd “I want to learn about angular. I think I
can raise my rates.” “I want to learn about Angular. I think I can raise my rates.” ! That is almost certainly true.

DevMynd “We have an ancient backbone.js setup that desperately needs
a rewrite…not sure in what.” Finally: “We have an ancient Backbone.js setup that desperately needs a rewrite but we’re not sure in what.” ! By ‘ancient’ here, she meant, like, 6 months old. ! So, no matter what direction they were approaching front-end development from, all these folks had the same overarching question:

What JavaScript framework should I use? http://www.ﬂickr.com/photos/hakkiceylan/5043637183 What JavaScript framework
should I be using? ! This is one the big open questions in web app development right now.

It’s an open question because of all of this. This
is a great problem to have! There are so many options! ! And even though it seems like we have some front- runners emerging, it’s still early. I made this slide 4 months ago, and it already feels a bit dated. The landscape is chaotic and very confusing. ! Every technical community that’s evolving has some question like this - in fact usually more than one.

They’re questions that lots of people are wondering about, lots
of people are talking about, and lots of people have opinions about that they really, really want to tell you.

What data store should I use? http://www.flickr.com/photos/hakkiceylan/5043637183 For example, back-end
developers have another open question right now: “which datastore should I be using?” Postgres, mongo, cassandra, redis, hbase, so many choices! And when you’re a developer with a specific project in mind, it’s hard to tell what the right answer is. ! The internet has a ton of information about this stuff, but it’s really hard to sift through and find the things that are really useful.

http://www.ﬂickr.com/photos/57340921@N03/6663307997 Fun fact: if you google “how to pick a
javascript framework,” there are two pages of results from the last six months. Unfortunately, as a collection, they’re about as helpful as this collection of parking signs. ! Look at that and tell me whether or not you can park there at noon on a Tuesday.

http://www.ﬂickr.com/photos/57340921@N03/6663307997 This confusing and seemingly contradictory information was in evidence
even at Fluent. One talk would say Ember is great for [X] — data binding, or whatever — and then in the same room in the next time slot was a talk saying Angular is best for [X]. ! Your job is to synthesize all this data into a decision. No pressure! But it’s important, because the cost of being wrong is high. It’s not just are you parking illegally, might you get a $30 ticket? If you pick a JavaScript framework unsuited to your project, it can be disastrous.

http://www.ﬂickr.com/photos/cgpgrey/4887121259 You hear stories, especially at conferences, about bad decisions
with catastrophic results - “we stored our data in Mongo, then one day it disappeared!” - but usually the consequences of a bad technology choice are not as dramatic as all that.

https://www.ﬂickr.com/photos/andrewpescod/273722236 Usually a suboptimal technology choice manifests itself as a
drag on the project that can start out being quite subtle. But it always gets worse as time goes on. Features become harder to add. It feels like you’re ﬁghting the framework every step of the way.

https://www.ﬂickr.com/photos/coreywagehoft/5010106344 Many companies just live with the drag of technology
choices that are no longer appropriate. There are plenty of reasons beyond sunk cost to do that — maybe the time it takes to retrain on something else outweighs the time you’d save switching to something better.

https://www.ﬂickr.com/photos/telstar/2562995652 And who really knows if the new thing would
be better, anyway? These days everyone wants to do microservices to refactor big-ball-of-mud macroservices. But they often just end up with a distributed ball of mud that’s harder to work with than the original. ! Identifying the actual problem slowing you down is surprisingly hard.

https://www.ﬂickr.com/photos/macca/2055827643 One thing to note, though, is that any team
living with this technology drag is a prime candidate for startup disruption. ! Paul Graham from YCombinator has made a lot of money betting on companies doing exactly this.

https://www.ﬂickr.com/photos/bolonski/4134530167 So we want to be able to make these
large-scale decisions correctly. The ﬁrst time. ! To avoid this catastrophic case…

https://www.ﬂickr.com/photos/adwheelerphoto/14034148123 …and also to avoid this slow decline. ! Unfortunately
for us, we don’t make these decisions very often, which removes as an option one of the primary ways that we learn. ! One of the most effective ways for human brains to learn is by repetition. Now I’m sure you’ve heard this before. Because in our programming pop culture, we have a meme for this.

http://www.ﬂickr.com/photos/celestinechua/9687401410 The meme is: it takes 10,000 hours of practice
to get great at something, like playing an instrument, or programming, or…whatever this person is doing. It’s a drastic over-simpliﬁcation of how people learn, but it’s persistent, partially because it has a kernel of truth in it.

https://www.ﬂickr.com/photos/rebeccaanne/4903959901 That kernel is that repetition is a very powerful
way for human beings to learn. The key, though, is not just the time spent - it’s how you spend that time. ! You can spend 10,000 hours on something, but if they’re not the right kind of practice, those hours are wasted.

http://www.ﬂickr.com/photos/103573073@N07/10459278644 To really learn by repetition, you have to do
the action, analyze the outcome, and then repeat the action, changing it a little bit — this is the important part — changing it to see if that changes the outcome. ! Even once you think you’ve got it, even once you think you’ve got that perfect cursive letter L, you need to keep experimenting. Keep trying new things. That’s where the learning actually happens.

http://www.ﬂickr.com/photos/103573073@N07/10459278644 If only we made large-scale technical decisions as often
as this kid is doing his cursive letter L. If only we could wait - 10 years, 15 years - to accumulate enough experience with this type of thing. ! Well - we can’t do that. At least not right now.

http://www.ﬂickr.com/photos/103573073@N07/10459278644 But we can make an end run around this
limitation by analyzing the decisions we do make all the time, and bringing that intel back to the framework choice.

DevMynd Libraries from Github Frameworks Languages DECISION FREQUENCY: Every day
Rarely Variable/class names, etc. Because our decision making happens at different scales, and different frequencies. Language and framework choices are the most infrequently made decisions. But, there are a few things we do more frequently, such as decide whether to use some random code you found on github, or roll your own. ! And even more frequently than that are the technical decisions we make every day — things like “where does this code go? what should I call this variable? should I write a test now?”

http://www.ﬂickr.com/photos/columodwyer/11200346004 But even at the smallest, most frequent level, the
process we use to make these decisions is pretty opaque. ! Ask a programmer why they named a variable that way, or why they put that function where they put it, and often all they can tell you is “well, ah, it just seemed like the right thing to do?” Sometimes you get an answer like “experience.” “Intuition.” “Gut feeling.”

http://www.ﬂickr.com/photos/columodwyer/11200346004 When I ask a programmer why they like Ember
over Angular, or the other way around, I often get very similar opaque responses. “It feels more natural,” is one that I hear a lot. I’ve heard it said about both Ember and Angular, by different people.

http://www.ﬂickr.com/photos/tulanesally/3638658173 I wanted to investigate what goes into that feeling.
What data do we collect, how do we organize it, and what do we do with it?

DevMynd Every day Rarely Higher risk, lower frequency Lower risk,
higher frequency DECISION FREQUENCY: Libraries from Github Frameworks Languages Variable/class names, etc. We want to get insights into these high risk, low frequency decisions, so we’re going to look at these lower risk, higher frequency ones. ! I asked a bunch of my colleagues to introspect for me, and describe how they evaluate a package that they’re considering using in their project.

•Interface http://www.ﬂickr.com/photos/36844288@N00/6810750734 It turns out that everyone starts in the
same place. They go to Github & they look at the README — a time- honored documentation format. This is a README from 1936 on how to operate a telephone. ! What are they looking for? The features, the functionality, and the usage of the code. Basically they’re looking at the interface of the package — what does it do and how do you use it. This information is usually easy to ﬁnd in bullet points right there, like it is here. To operate, to answer, to clear, to make calls.

•Interface http://www.ﬂickr.com/photos/36844288@N00/6810750734 Let’s consider an example evaluation. Let’s say you’re
trying to pick a ruby package (called a “gem”) to make HTTP requests.

http://www.ﬂickr.com/photos/dirtyf/2191026054 Making http requests via GET and POST and so
forth is how you use the tubes of the internet. It’s how you interface with any external API, so on many web projects, a package to easily do this type of thing is a fairly basic building block.

DevMynd INTERFACE HTTPARTY FARADAY https://github.com/lostisland/faraday https://github.com/jnunemaker/httparty A search turns up
two contenders from Ruby land, the ﬁrst called “httparty” — which I’m actually not sure how to pronounce — and the second called “faraday.” Assuming you don’t dismiss httparty out of hand for pronunciation reasons, when you look at the README for the projects, this is what you’ll ﬁnd. ! I made the code deliberately small because I don’t want you to actually read it. I’ll point out the interesting bits.

DevMynd HTTPARTY FARADAY INTERFACE https://github.com/lostisland/faraday https://github.com/jnunemaker/httparty httparty has static methods,
also called class methods, that you can call directly. Alternatively, you can include its HTTP call methods into your own object.

DevMynd HTTPARTY FARADAY INTERFACE https://github.com/lostisland/faraday https://github.com/jnunemaker/httparty Faraday takes a different
approach, and gives you a connection object that you use to make the calls. ! Both interfaces will work. So…how do you pick one? Interface by itself is not enough for you make a decision. Just like a bullet list of the features of a framework aren’t enough to tell you if it’s worth using. ! So if this isn’t sufficient, what else do we think about? Here’s what I got from interviewing a bunch of folks:

DevMynd •Read README (Github) •Frequency/recency of commits (Github) •Number &
age of issues (Github) •Comments on issues & pull requests (Github) •Number & recency of tutorials/blog posts (Google) •Relative popularity to similar gems (Ruby Toolbox) •Date of last release (Rubygems) •Number & answer status of Stack Overflow questions •Opinions of work colleagues •Opinions on Twitter •Hacker News/Reddit discussions •Opinions of outside developers (email, IM, etc.) •Recency & completeness of official documentation •Availability of books •Mentions on screencasts/podcasts •Evaluate code directly (Github) •Evaluate the tests (Github) •Drop it in and see what happens •Build a sample app around it EVALUATION When Ruby developers are evaluating two similar gems, these are the things they do. It’s a long list. I had to move the font size way down to get it to fit. And it’s not exhaustive. I could put more. ! I want to point out a few interesting features it has.

age of issues (Github) •Comments on issues & pull requests (Github) •Number & recency of tutorials/blog posts (Google) •Relative popularity to similar gems (Ruby Toolbox) •Date of last release (Rubygems) •Number & answer status of Stack Overflow questions •Opinions of work colleagues •Opinions on Twitter •Hacker News/Reddit discussions •Opinions of outside developers (email, IM, etc.) •Recency & completeness of official documentation •Availability of books •Mentions on screencasts/podcasts •Evaluate code directly (Github) •Evaluate the tests (Github) •Drop it in and see what happens •Build a sample app around it 1 2 EVALUATION The first is that different people rank these differently. I always poke around on Github first to establish that is has a reasonable interface and activity, and then I ask my co-workers for input. But one of the people I talked with works at a company displaying ignorance is not really a good thing, so he never asks his co-workers. He goes straight for documentation and tutorials after he does the initial foray into github. ! So that’s the first thing.

age of issues (Github) •Comments on issues & pull requests (Github) •Number & recency of tutorials/blog posts (Google) •Relative popularity to similar gems (Ruby Toolbox) •Date of last release (Rubygems) •Number & answer status of Stack Overﬂow questions •Opinions of work colleagues •Opinions on Twitter •Hacker News/Reddit discussions •Opinions of outside developers (email, IM, etc.) •Recency & completeness of ofﬁcial documentation •Availability of books •Mentions on screencasts/podcasts •Evaluate code directly (Github) •Evaluate the tests (Github) •Drop it in and see what happens •Build a sample app around it EVALUATION The second is that no one does all of these for any given evaluation. Generally, though, the riskier a decision is, the more of them we do.

age of issues (Github) •Comments on issues & pull requests (Github) •Number & recency of tutorials/blog posts (Google) •Relative popularity to similar gems (Ruby Toolbox) •Date of last release (Rubygems) •Number & answer status of Stack Overflow questions •Opinions of work colleagues •Opinions on Twitter •Hacker News/Reddit discussions •Opinions of outside developers (email, IM, etc.) •Recency & completeness of official documentation •Availability of books •Mentions on screencasts/podcasts •Evaluate code directly (Github) •Evaluate the tests (Github) •Drop it in and see what happens •Build a sample app around it EVALUATION And the last thing is that this list changes both over time within a community, and across communities. Pre-2005, most discussion on Ruby libraries took place on the official Ruby mailing list. But there are no mailing lists in our top 25 today. ! If you made this list for the modern Python community, on the other hand, it would definitely include some mailing lists.

age of issues (Github) •Comments on issues & pull requests (Github) •Number & recency of tutorials/blog posts (Google) •Relative popularity to similar gems (Ruby Toolbox) •Date of last release (Rubygems) •Number & answer status of Stack Overﬂow questions •Opinions of work colleagues •Opinions on Twitter •Hacker News/Reddit discussions •Opinions of outside developers (email, IM, etc.) •Recency & completeness of ofﬁcial documentation •Availability of books •Mentions on screencasts/podcasts •Evaluate code directly (Github) •Evaluate the tests (Github) •Drop it in and see what happens •Build a sample app around it EVALUATION So the way we collect and use this data turns out to be pretty complicated. Let’s see if we can categorize it some and make some sense out of it.

DevMynd •Frequency/recency of commits (Github) •Number & age of issues
(Github) •Comments on issues & pull requests (Github) •Number & recency of tutorials/blog posts (Google) •Relative popularity to similar gems (Ruby Toolbox) •Date of last release (Rubygems) •Number & answer status of Stack Overflow questions •Opinions of work colleagues •Opinions on Twitter •Hacker News/Reddit discussions •Opinions of outside developers (email, IM, etc.) •Recency & completeness of official documentation •Availability of books •Mentions on screencasts/podcasts •Evaluate code directly (Github) •Evaluate the tests (Github) •Read README (Github) •Drop it in and see what happens •Build a sample app around it Interface README, use gem EVALUATION The first thing I noticed is that most of this is not technical data about the package. Most of it is social data. ! Let’s pull the technical data out first. As we talked about before, this is what everyone starts off with. They look directly at the features & functionality of the gem. Not the internals - the external Interface. We’ll put that stuff over here.

DevMynd •Number & recency of tutorials/blog posts (Google) •Relative popularity
to similar gems (Ruby Toolbox) Activity Commits, issues, PRs, releases, docs •Frequency/recency of commits (Github) •Number & age of issues (Github) •Comments on issues & pull requests (Github) •Date of last release (Rubygems) •Recency & completeness of ofﬁcial documentation •Number & answer status of Stack Overﬂow questions •Opinions of work colleagues •Opinions on Twitter •Hacker News/Reddit discussions •Opinions of outside developers (email, IM, etc.) •Availability of books •Mentions on screencasts/podcasts •Evaluate code directly (Github) •Evaluate the tests (Github) EVALUATION Interface README, use gem Once we remove the technical data, another category makes itself apparent. ! These things are information about the Activity of a project. How often is it updated? How likely am I to get help from the maintainer or get a pull request merged? We’ll pull these out over here, and give ourselves a little more space to see what’s left.

DevMynd •Number & recency of tutorials/blog posts (Google) •Relative popularity
to similar gems (Ruby Toolbox) •Number & answer status of Stack Overflow questions •Opinions of work colleagues •Opinions on Twitter •Hacker News/Reddit discussions •Opinions of outside developers (email, IM, etc.) •Availability of books •Mentions on screencasts/podcasts Popularity SO, HN, Google •Evaluate code directly (Github) •Evaluate the tests (Github) EVALUATION Interface README, use gem Activity Commits, issues, PRs, releases, docs These things are information about the project's Popularity among other developers. How easy will it be to find help when I run into a problem? Can I hire someone? How likely is it that someone else has already fixed a bug by the time I encounter it? ! We’ll pull that stuff out over here, and now we’re left with a couple of outliers.

DevMynd •Evaluate code directly (Github) •Evaluate the tests (Github) Accessibility
Look at code EVALUATION Interface README, use gem Activity Commits, issues, PRs, releases, docs Popularity SO, HN, Google Reading the code, and reading the tests. They don’t ﬁt in the groups we have so far. Interface, Activity, and Popularity are all pretty straightforward, with well-known sources of data. But what we have left is a little fuzzier. ! It’s really about how familiar things feel to you. Is this code idiomatic? How much does the code match up with what I would write if I were going to roll my own? How much does this code feel like other code I’ve seen? I call this Accessibility.

DevMynd Accessibility Look at code EVALUATION Interface README, use gem
Activity Commits, issues, PRs, releases, docs Popularity SO, HN, Google So there’s our last group. These are, broadly speaking, the four categories of data that we consider when we’re making a decision. Once I got to this point, I sort of squinted at them, for a while, and I realized that you could actually group them in two different ways.

•http://dashes.com/anil/images/jobs-iphone-quadrants.jpg Now, stay with me here, we’re about to make
quadrants! Apparently it’s a thing.

Popularity Interface Activity Accessibility Internal External So, here we go.
First off, you can draw one line here. The two categories on the top - accessibility and interface - are both about you. Interface is about whether the code can actually do what you need it to do for your project, and accessibility is whether your team feels comfortable with the metaphors the project uses & its code.

Popularity Interface Activity Accessibility Internal External On the bottom, those
two categories are about the people and the project outside of your team. Popularity and activity measure external factors. ! So we do have a divide between internal categories and external categories.

Project People Popularity Interface Activity Accessibility Internal External Then there’s
another line you can draw top to bottom. On the left side, accessibility and popularity both have to do with the people around a project. Accessibility is whether or not your people can use it. Popularity is whether other people are using it.

Project People Popularity Interface Activity Accessibility Internal External Then on
the right side, Interface and Activity are both information about the project itself. The interface, as we said, is whether the framework does everything you need for your project. And activity, while it’s generated by people, is ultimately about the project. It’s about whether you can bet on bug ﬁxes & improvements down the line. ! So there you go, there’s my four-quadrant system for making difficult technical decisions.

Project People Popularity Interface Activity Accessibility Internal External I was
showing this talk to this friend and we got to this part and he was like “This is awesome, because, you know, consultants are supposed to have a system they’re selling. Now you’ve got one and it even has the right number of quadrants.” ! And I looked at him and I thought, you know, if I’m going to own this, it has to have a suuuuper narcissistic title.

The Mei System Internal External Project People Popularity Interface Activity
Accessibility So there we go. “The Mei System.” Now if this really makes you want to throw lots of money at me…uh, let me know? But otherwise I think I’m just going to stick to my pair programming approach. ! So far, this maybe isn’t super useful. All we’ve done is capture the practices that people actually do into categories.

http://www.ﬂickr.com/photos/drift-words/99645 And categories, while they can be useful, really only
become powerful when we apply them to the higher-risk problems. So let’s look at how to apply these categories to higher-risk problems. ! Er, not these categories…although, that also seems like it would be an interesting talk.

Internal External Project People Popularity Interface Activity Accessibility These. Let’s
start with Interface. It’s pretty straightforward. The interface of a framework is what’s in the angular readme, the ember readme, the intro tutorials. These are the bullet lists of features that make up most blog posts and talks about picking a framework.

Internal External Project People Popularity Interface Activity Accessibility Next, Activity…this
is largely the same as at the smaller scale, too. You can get this by looking at the github project, looking at the release schedule, and looking at the docs.

Internal External Project People Popularity Interface Activity Accessibility Next, Popularity,
also largely the same. Stack overﬂow content, percentage of Hacker News arguments, number of recent blog posts.

Internal External Project People Popularity Interface Activity Accessibility Accessibility -
this one is a little bit different. Once again, it’s kind of the interesting one. Because in the JS framework landscape today, there are multiple frameworks with sufficient interfaces, sufficient popularity, and sufficient activity.

Right? This is where we are. Backbone, Angular and Ember.
! All three of these will do what your application needs. They’re all reasonably popular. They’re all reasonably active. Accessibility is how we distinguish these frameworks from each other. ! To make this more concrete, let’s look at what an accessibility judgement looks like at the small scale, and then at the large scale.

DevMynd HTTPARTY FARADAY Add http call functionality to your object
Keep http functionality in a separate object INTERFACE https://github.com/lostisland/faraday https://github.com/jnunemaker/httparty So let’s go back to our http library example. Both of these libraries have a sufficient interface - both will allow you to place any kind of http call. They’re both actively maintained, and are both heavily used. But they feel different. ! We can sum up the differences this way: *If you come from a procedural background, the upper approach will feel better. *But if you’ve done a lot of object-oriented programming, the lower approach feels better.

http://www.ﬂickr.com/photos/betchaboy/6325132427 That’s what Accessibility is all about. Do you identify
with the style of the code? That’s even more important when you’re talking about frameworks, because those will affect the code you write way more than an http gem will. ! But it’s not always as easy to untangle with frameworks as it is in our http example. But let’s try. Now that we’ve seen what accessibility means in the small scale, let’s look at what it means in the larger scale.

http://cdn.arstechnica.net/wp-content/uploads/2011/10/dart-sharks-4e95fbf-intro.jpg I want to start with a little history of
how Java and JavaScript have historically gotten along, which is not very well. For a long time, Java web framework land was a very sad place to be if you were JavaScript.

http://www.ﬂickr.com/photos/kawaii77/31896862 The state of the art, for a while, was
something called “Java Server Faces.” They are packaged front-end widgets, usually with a really old version of jQuery thrown in there. ! To put one on your page, you put a little directive into your markup and it would spew JavaScript into your page. It hooked up automatically to your backend, and you never had to write any JavaScript. This was considered a feature.

http://www.ﬂickr.com/photos/3059349393/3801594313 For years now, the Java community has put a
pretty intense amount of effort into avoiding JavaScript entirely. ! There were other efforts in this direction. Remember GWT, google web toolkit? Write Java, compile down to JavaScript. There are more modern approaches, too, like Dart. They are basically all efforts to allow Java developers — of which there are hundreds of thousands — to write JavaScript without actually having to learn it.

However these days there is a new contender: Angular.js. Written
by Java developers, and featuring a dependency injection structure eerily similar to those found in modern Java backend web frameworks. ! If you come from the Java backend world, or .NET, where dependency injection frameworks are standard practice, Angular will feel familiar. Accessible.

Angular is a huge step forward for the Java world.
It’s actual JavaScript — that’s great! — with a structure layered on top to make it less risky for them to adopt it. They can do heavy-duty JavaScript, without having to learn an entirely new development paradigm.

•http://www.ﬂickr.com/photos/theknowlesgallery/4714085113 Conversely, for those of us who don’t come from
Java or .NET, the dependency injection in Angular will feel disorienting. Fun! But disorienting. That makes adoption riskier, because we’ll have to take on the cognitive load of understanding the framework in addition to trying to actually get shit done.

•http://www.flickr.com/photos/theknowlesgallery/4714085113 Now of course there’s a learning curve on any
javascript framework. But finding a framework that fits the way you already think makes adoption less risky. ! And that’s what accessibility measures, at its core. It’s a measure of how steep the learning curve is likely to be for your team.

Next we have ember.js, with a mascot that I think
we’ve decided is a hamster. It’s not QUITE as creepy as the Go gopher.

•http://www.gophercon.com/img/logo.png This may be the creepiest conference logo I have
ever seen. Anyway! Back to our friendly hamster.

Ember.js - built by Rails developers, and featuring at the
center of all ember applications, a router! ! The router is a piece of code that takes in a request, and decides what code to run as a result. It’s eerily similar to what’s at the center of all Rails applications.

This concept that the routes determine what code gets called
ﬂows from REST. So, if you come from a web framework that matured in the RESTful-era, such as Rails, or Django, Ember.js is going to feel very accessible. It’ll feel easy. Natural. ! On the other hand, if you come from Java or .NET or another web framework that matured before REST was a popular thing, you are used to having much more control over what exactly happens to a request.

http://www.ﬂickr.com/photos/deanspic/4960440218 So, for you, ember may feel a little overly
constrained.

And ﬁnally: Backbone.js, the grand-daddy of them all. ! Backbone
was graduated out of a Rails app in the 2008-2009 timeframe. And I know it’s hard to think back that far, but that was before the idea of single-page apps was a thing.

There were one or two people doing things with, like,
Cappuccino over in a corner, but really most people thought about JavaScript as something that decorated server-rendered pages. So you’d render a view, assemble some JavaScript, shove them down a pipe to a client, and once they got there, the JavaScript would add a veneer of interactivity over the markup. ! And if that’s how you still think about “web applications,” then Backbone, or one of its more fully-featured variants, will feel natural. Easy. Straightforward.

But if you’re one of those kids today who think
about a “web application” as a bunch of JavaScript that runs in a browser, creates some markup, and goes out to the internet to get data once in a while, then Backbone feels completely wrong. ! So for this framework, the accessibility judgement ﬂows from the type of projects you’ve done, rather than the technologies you’ve done them in, as in Angular and Ember. !

http://www.ﬂickr.com/photos/gsfc/4690804595 Accessibility judgements come from many different sources when we’re
talking about frameworks, because they’re more complex than a simple gem. One source is the technology stacks you’ve worked with. Another source is the type of projects you’ve done.

Project People Popularity Interface Activity Accessibility Internal External And for
any given decision, accessibility is the most difficult of these to ﬁgure out.

http://www.ﬂickr.com/photos/wyscan/22754672 Because it’s not like the Angular folks have a
bullet point in their README that says “by Java developers, for Java developers!” ! Everyone who’s building a framework thinks they’re building it for everyone. But they’re all wrong.

http://www.ﬂickr.com/photos/seattlemunicipalarchives/2713475713 They’re actually just codifying their own bias. ! So
how do you see that? Besides, I suppose, coming here and listening to me rant. Well, as fun as it is to talk about it, you probably don’t actually need to know what their biases are when you’re making a decision, because you’ll be able to feel how well they line up with yours. Notice the amount of ease, or unease, you feel when you use a framework.

Project People Popularity Interface Activity Accessibility Internal External And remember
that even once you’re explicitly thinking about accessibility, it may not always be the most important factor in your decision.

Project People Popularity Interface Activity Accessibility Internal External Sometimes, you
have a team that is overtaxed and you need a way to adopt a new technology that is as close as possible to what they already know. In that case, accessibility is the major factor in play. ! But other times your team is ready & willing to be pushed in new directions, so accessibility takes a back seat to other considerations.

Project People Popularity Interface Activity Accessibility Internal External Sometimes you
want popularity because you know you’ll need to hire 5 people and the timeframe is short.

Project People Popularity Interface Activity Accessibility Internal External Sometimes you
pick something totally unpopular & new because it has that one feature that you need. ! It’s your business that determines the relative importance of each of these quadrants. But when you’re making a decision, just make sure you’re considering all four.

DevMynd OH, HACKER NEWS… https://twitter.com/steveklabnik/status/444147360856551424 I want to close with
something I saw on Hacker News awhile back. ! The context is a blog post about Nimrod, an obscure programming language. And one of the commenters talks about all the great features it has, how great its interface is, and then he says, “The only reason Nimrod isn’t popular is that people don’t evaluate things logically.” And he was clearly very frustrated. Now I actually really sympathize with his point of view.

Project People Popularity Interface Activity Accessibility Internal External Because the
decisions that other people make really do look mysterious if you think that this is all there is to think about when you’re evaluating a technology. ! Nimrod is failing to catch on. But not because people are illogical.

http://www.ﬂickr.com/photos/alexschwab/9205086243 It’s failing to catch on because their logic extends
further than that guy can see from down here. ! You can’t repeat the language or framework decision often enough to learn from repetition, but you can take these categories and let them expand your vista when you’re thinking about a large-scale technical decision.

“A change in perspective is worth 80 IQ points.” Alan
Kay http://www.ﬂickr.com/photos/alexschwab/9205086243 As a very wise man once said, “a change in perspective is worth 80 IQ points.” Alan Kay is an OG computer scientist, who, among other things, invented object- oriented programming. Smart guy. ! And I’d say with the things we’re thinking about - a change in perspective is worth 80 IQ points, and 5 years of experience.

http://practicalrailsbook.com Sandi Metz & Sarah Mei That’s all I’ve got.
Thank you. ! I’m writing a book with Sandi Metz about refactoring large rails apps. Go check it out at practical rails book .com if that is relevant to your interests.

Sarah Mei [email protected] @sarahmei THANKS! Questions? Twitter or (if you
must) email is the way to go. =)

Most photo credits are inline. Others: •Slide 1: http://www.flickr.com/photos/loop_oh/4621885147/ •Slides
3, 4, & 5 top right: http://www.ministryofvelocity.com/ http://pivotallabs.com •Slide 3, 4, 5, 107: http://www.devmynd.com/ •Slide 4 & 5, bottom row: first three are from http://rubycentral.org •Slide 4 & 5, bottom row: last one is from http://railsbridge.org •Slide 6 & 7: http://ruby-lang.org https://github.com/voodootikigod/logo.js •Slide 106: http://practicalrailsbook.com ! •ALL THE LOGOS •Ember logo (slides 21, 26, 27, 76, 86, 88, 89): http://emberjs.com/ •jQuery logo (slide 22): http://jquery.org/ •Angular logo (slides 23, 26, 27, 76, 82, 83): http://angularjs.org/ •Backbone logo (slides 24, 26, 27, 76, 91, 92, 93): http://backbonejs.org/ •Other logos from slides 26 & 27: •Ionic: http://ionicframework.com/ •can.js: http://canjs.com/ •Rendr: http://github.com/rendrjs/rendr •Enyo: http://enyojs.com/ •Rikulo: http://rikulo.org/ •Flight: http://twitter.github.io/flight/ •Polymer: http://www.polymer-project.org/ •Meteor: http://www.meteor.com/ •BladeRunner: http://www.caplin.com/developer/component/bladerunner •React: http://facebook.github.io/react/ •Evening Starlight: http://friendshipismagicfanon.wikia.com/wiki/Evening_Starlight

Unpacking Technical Decisions - NDC London 2014

Unpacking Technical Decisions - NDC London 2014

More Decks by sarahmei

Other Decks in Technology

Featured

Transcript