Sarah Mei Ministry of Velocity @sarahmei Unpacking Technical Decisions Hiya! I’m Sarah Mei, and I run a consulting company in San Francisco called the Ministry of Velocity. I spend my days helping people refactor large Ruby and JavaScript codebases. ! I wasn’t supposed to be speaking at MWRC this year. I spoke last year, so I was on the program committee this year, which meant I got to read all the talk proposals people submitted during the CFP. I think we picked a good program, but we failed to do one critical thing: designate backup speakers. ! Soooooo here I am. Fortunately I did this talk last week, at Fluent, an O’Reilly conference covering JavaScript, CSS, and HTML. Here’s a picture:

People at Fluent http://www.flickr.com/photos/oreillyconf/8893292969 I think about Fluent as the conservative JS conference. And by the way, you can tell it’s an O’Reilly conference because they sprung for the expensive “no-flip” name tags. :) ! Anyway…Fluent is not the type of conference I normally do. I normally hang out with Ruby folks. Totally different crowd. So I spent a lot of time in the hallways talking to people — interrogating them, basically — asking them who they were and why they were there. It was super interesting. The people I met fell into three categories:

of PEOPLE AT FLUENT •Back-end developers •Visual & interaction designers •Front end developers 1. Back-end developers, looking to learn more about front-end development, because all the cool kids are “full stack” developers… 2.Visual and UX designers, coming at front-end development from the other direction, and… 3.Front-end developers. Unsurprisingly, this was the largest group. ! These are three groups of people with very different past experiences. And they surprised me, because when I asked about specifically why they were there, they all told me the same thing. ! Here are some quotes I wrote down. See if any of them sound familiar.

of PEOPLE AT FLUENT “My group has started an ember project, so I’m going to every ember.js talk on the schedule.”

of PEOPLE AT FLUENT “My web app has an old jQuery codebase and I need to figure out what to do with it.” One thing I learned at Fluent is that some people have a deep and abiding hatred for jQuery.

of PEOPLE AT FLUENT “I want to learn about angular. I think I can raise my rates.” This is almost certainly true.

of PEOPLE AT FLUENT “We have an ancient backbone.js setup that desperately needs a rewrite…not sure in what.” I think by ‘ancient’ here, she meant, like, 6 months old. ! So, no matter what direction these folks were approaching front-end development from, they all had the same burning question.

What JavaScript framework should I use? http://www.flickr.com/photos/hakkiceylan/5043637183 What JavaScript framework should I be using? This is one the big open questions in web app development right now. I suspect many of you reading this have some version of that question on your mind. ! It’s an open question because of this:

Wooooaaaah! I mean, this is a great problem to have, because there are so many options! But unfortunately…there are so many options. And even though it seems like, these days, we do have some front-runners emerging, it’s still early. I mean, Ionic (upper left hand corner), just got a million dollars in funding, like, last week. It’s early days, I’d say, and it’s very confusing. ! Every technical community that’s evolving has something like this. They’re questions that lots of people are wondering about, lots of people are talking about, and lots of people have strong opinions about that they really, really, REALLY want to tell you about. ! For example, if you’re a Rails developer, you have another open question right now, and that is…

What data store should I use? http://www.flickr.com/photos/hakkiceylan/5043637183 …“which datastore should I be using?” PostgreSQL, MongoDB, Cassandra, Redis, Riak…so many options. When you’re a developer with a specific project in mind, looking at either of these questions, it’s hard to tell what the right answer is. ! The internet has a ton of information about this stuff, but unfortunately…the internet has a ton of information about this stuff, and it’s really hard to sift through and find the things that are really useful. Fun fact: if you google “how to pick a JavaScript framework,” as of last week, there are two pages of results from the last six months.

http://www.flickr.com/photos/57340921@N03/6663307997 Unfortunately, as a collection, those articles are about as helpful as this collection of parking signs. So look at that and tell me whether or not you can park there at noon on a Tuesday. (I’m not waiting.) ! I mean, of course, that they give you confusing and seemingly contradictory information. That seemed to be the case even at Fluent. One talk would say ember is great for [X], and then in the same room in the next time slot was a talk about angular that said angular is clearly superior for [X]. Data binding, or whatever. 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 “might you get a $30 ticket?” If you pick a JS framework that isn’t suited to your project, it can be disastrous, depending on when you find out.

http://www.flickr.com/photos/cgpgrey/4887121259 How far down the road are you going to go, before you realize that there’s no more road? ! These decisions are big, and they are scary. And we want to be able to get better at them. Unfortunately, we don’t make these decisions very often. And one of the most effective ways for our human brains to learn is by repetition. I’m sure you’ve heard that before. ! Because in our programming pop culture, there’s a particular meme…

http://www.flickr.com/photos/celestinechua/9687401410 …this one. Here’s an “inspirational” image from the internets. ! The meme is that 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 makes me a little angry, actually, every time I see it. Not because of that horrendous drop shadow on the text, though it is pretty bad. It makes me angry because it’s such an over-simplification of how people learn a skill. ! This meme is persistent partially because it has a kernel of truth in it, which 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 10k hours on something, but if you’re not doing it right, those hours are wasted. To really learn by repetition, you have to do the action…

http://www.flickr.com/photos/103573073@N07/10459278644 …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 can do that cursive letter L, you need to keep experimenting. Keep trying new things. That’s where the learning actually happens. ! As a side note, my daughter’s in third grade, and they don’t teach cursive any more. At all. She doesn’t do these worksheets that I remember doing. Makes me feel old. She has, however, known how to operate an iPad since she was 2. So…I guess I’m hoping that’s a more useful skill than cursive in this new world. ! But in any case, repetition is a powerful way for us to get better at something like large-scale technical decision making. If only we did it as often as Noah is doing his cursive letter L. If only we could wait 10 years, or 15 years, to accumulate enough experience with this type of thing. ! Well - we can’t do that. At least not right now.

http://www.flickr.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 information back to the framework choice.

of Libraries from Github Frameworks Languages Decision Frequency THE DECISION PYRAMID Every day Rarely Everyday code decisions We can do this 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. ! 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.flickr.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.” ! 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 the way. ! I wanted to investigate what goes into that feeling.

http://www.flickr.com/photos/tulanesally/3638658173 What data do we collect? How do we organize it? What do we do with it?

of Decision Frequency THE DECISION PYRAMID Every day Rarely Everyday code decisions Libraries from Github Frameworks Languages Higher risk, lower frequency Lower risk, higher frequency We want to get insights into these higher-risk, lower-frequency decisions, like choosing a framework. So we’re going to look at the decisions one level up. ! Because it turns out, I know a lot of people who evaluate libraries off Github all the time. I asked a bunch of my colleagues to introspect for me, and describe how they evaluate a gem that they’re considering using in their project. And it turns out that they all start in the same place. They go to Github and they look at the README.

Interface http://www.flickr.com/photos/36844288@N00/6810750734 This is a README that slightly predates Github. :) It’s a README from 1936, covering how to operate the telephone. ! When people come to a README, they’re looking for the features, the functionality, and the usage of the code. Basically they’re looking at the interface of the gem — what does it do and how do you use it? This information is easy to find because it’s usually in bullet points right there: “to operate,” “to answer,” “to clear,” “to make calls.” ! Let’s consider a real evaluation and see how it goes. Let’s say you’re trying to pick a gem to make HTTP requests.

http://www.flickr.com/photos/dirtyf/2191026054 Now we all know that making http requests is how you construct the tubes that make the internets. We want to use the tubes, so we need a gem to make http requests.

of THE INTERFACE HTTPARTY FARADAY https://github.com/lostisland/faraday https://github.com/jnunemaker/httparty A google search turns up two contenders from Ruby land, the first called “Httparty” — which I’m actually not sure how to pronounce — and a second called “Faraday.” So assuming you don’t dismiss Httparty out of hand because you don’t want to keep saying it, you look at the README for each project, skip to the usage section, and this is what you’d find: ! You don’t need to actually read all this code — I’ll point out the interesting bits.

of THE INTERFACE HTTPARTY FARADAY https://github.com/lostisland/faraday https://github.com/jnunemaker/httparty 1 2 3 4 Httparty has static methods [1], or you can include its HTTP call methods into your own object [2]. ! Faraday takes a different approach, and gives you a connection object [3] that you use to make the calls [4]. ! Both interfaces will work. Both will let you make any type of HTTP call you want. So looking at the README, 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 on your team. ! So what else do we think about? Here’s what I got from interviewing a bunch of folks:

of •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 TECHNIQUES When Ruby developers are evaluating two similar gems, these are the things they do. ! This is 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.

of •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 TECHNIQUES 1 2 2 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.

of •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 TECHNIQUES 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.

of •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 TECHNIQUES And the last thing is that this list changes as the community that generated it changes. For example, before Rails came along, a lot of discussion about Ruby libraries took place on the official English-language Ruby mailing list. But today, I don’t think it would occur to any of us to post to the official English-language Ruby mailing list when we’re trying to choose an HTTP gem. The Python community, on the other hand, relies heavily on email lists. ! All three of those things are pointing out that the way we collect and use this data is pretty complicated. But the most interesting thing about this list, actually, is that most of it isn’t technical data at all. It’s social data. It’s information about the people around a project — the maintainers and users.

of •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) EVALUATION TECHNIQUES •Read README (Github) •Drop it in and see what happens •Build a sample app around it Interface README, use gem There is some technical data - let’s pull that out first. 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.

of •Number & recency of tutorials/blog posts (Google) •Relative popularity to similar gems (Ruby Toolbox) EVALUATION TECHNIQUES 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 official documentation •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 •Evaluate code directly (Github) •Evaluate the tests (Github) Interface README, use gem OK. Now, 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.

of EVALUATION TECHNIQUES •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) Interface README, use gem Activity Commits, issues, PRs, releases, docs OK — most of this stuff that’s left is 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 who is already familiar with it? 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. What are these?

of EVALUATION TECHNIQUES Popularity SO, HN, Google •Evaluate code directly (Github) •Evaluate the tests (Github) Interface README, use gem Activity Commits, issues, PRs, releases, docs Reading the code, and reading the tests. They don’t really fit in any of the groups we have so far. Interface, activity, and popularity are all pretty straightforward. There are well-known sources of data for this information. But what we have left is a little fuzzier. ! It’s really about how familiar things feel to you. Is this code idiomatic Ruby? Does the maintainer share my test strategy? 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?

of EVALUATION TECHNIQUES Popularity SO, HN, Google •Evaluate code directly (Github) •Evaluate the tests (Github) Interface README, use gem Activity Commits, issues, PRs, releases, docs Accessibility Look at code Let’s call this accessibility. So there’s our last group. These are the four categories of data that we consider when we’re making a decision. Once I got to this point, writing this talk, I sort of squinted the circles for a while, and I realized that you could actually group them further 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 they’re 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. ! On the bottom, popularity and activity are about the people and the project outside of your team. So we have a divide, here, between internal categories and external categories.

Popularity Interface Activity Accessibility Internal External Project People Then there’s another line you can draw here. 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. ! Then on the right side, interface and activity are both information about the project itself. The interface, as we said, is whether the project does everything you need. And activity, while it’s generated by people, is ultimately about the project. It’s about whether you can bet on bug fixes & improvements down the line. ! So there you go. There’s my four-quadrant system for making difficult technical decisions. I was showing this talk to this friend and we got to this part and he was like “This is awesome, because you’re a consultant now. And consultants are supposed to have a system they’re selling. Now you’ve got one and it even has the right number of quadrants!!!11one” ! 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.

Popularity Interface Activity Accessibility Internal External Project People The Mei System So here 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 consulting approach. ! So we’ve got quadrants! Cool. But maybe isn’t super useful yet. All we’ve done is capture the practices that people actually do into categories.

http://www.flickr.com/photos/drift-words/99645 Categories are useful. These ones in the picture look pretty useful I think. But they 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, maybe not these categories. Although, that also seems like it would be an interesting talk. (Which framework goes in “Fish”?)

Popularity Interface Activity Accessibility Internal External Project People These categories. Let’s start with interface. At the framework level, as at the lower level, it’s pretty straightforward. The interface of a framework is what’s in the angular README, the ember README, and the intro tutorials. It’s the bullet lists of features that make up most blog posts and conference talks (*cough*) about picking a framework.

Popularity Interface Activity Accessibility Internal External Project People Next — activity. This is also largely the same as at the smaller scale. You can get this by looking at the Github project, looking at the release schedule, and looking at the docs.

Popularity Interface Activity Accessibility Internal External Project People Next — popularity. Also largely the same as at the small scale. Stack overflow content, percentage of Hacker News arguments, number of recent blog posts.

Popularity Interface Activity Accessibility Internal External Project People Finally — accessibility. This one is a little bit different. Once again, it’s kind of the interesting one. Because in the JavaScript framework landscape that we have 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, I want to show you what an accessibility judgement looks like at the small scale, and then at the large scale.

of THE INTERFACE HTTPARTY FARADAY https://github.com/lostisland/faraday https://github.com/jnunemaker/httparty Add http call functionality to your object Keep http functionality in a separate object So let’s go back to our HTTP library example. Both of these libraries have a sufficient interface. They’re both actively maintained, and are both heavily used. But using them feels different. ! If you come from a procedural background, the upper approach will feel better. It will feel more convenient. More natural. ! But if you’ve done a lot of object-oriented programming, single responsibility principle and all that, then the lower approach feels better. More natural. 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 frameworks affect the code you write way more than an HTTP gem does.

http://www.flickr.com/photos/betchaboy/6325132427 But it’s not always easy to untangle the makeup of an accessibility judgement at the framework level. Gems are relatively simple; frameworks are much more complex. But let’s try. Now that we’ve seen accessibility in the small scale, let’s look at it in the larger scale. ! I want to start with a little history of how Java and JavaScript have historically gotten along.

http://cdn.arstechnica.net/wp-content/uploads/2011/10/dart-sharks-4e95fbf-intro.jpg 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.flickr.com/photos/kawaii77/31896862 The state of the art, for a while, was something called “Java Server Faces.” I have never actually seen Java Server Faces, you can’t find them anywhere on my resume, and please never talk to me about them again. o_0 ! Java Server Faces are packaged front-end widgets, usually with a really old version of jQuery thrown in. And to put one on your page, you just put a little directive into your code and it will spew JavaScript into your page. It hooks up automatically to your backend, and you get JavaScript functionality in your pages without having to write any JavaScript. This is considered a feature.

http://www.flickr.com/photos/3059349393/3801594313 Over the years, the Java community has put a lot of effort into avoiding JavaScript entirely. Other efforts included GWT, google web toolkit. Write Java, compile down to JavaScript, what could possibly go wrong? 
 ! There are more modern approaches, too, like Dart. These are basically all efforts to allow Java developers — of which there are millions — to write JavaScript without actually having to learn it. ! However! These days things are looking up.

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. ! Hmm. ! So if you come from the Java backend world, or the .NET backend world, where dependency injection frameworks are standard practice, then Angular will feel familiar. Accessible. Natural. 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 JavaScript, without having to learn an entirely new development paradigm.

http://www.flickr.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, at first. 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. ! Now of course there’s a learning curve on any JavaScript framework, for any team. 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. !

Now of course Angular isn’t your only option. There’s Ember.js, with a mascot that I think we’ve decided is a hamster. It’s not quite as creepy as the Go gopher. I don’t know if you’ve seen the mascot for Go, the programming language.

http://www.gophercon.com/img/logo.png This may be the creepiest conference logo I have ever seen. Uh…I’m sure the conference will be great though! ! Anyway. Back to our friendly hamster.

Ember.js - built by Rails developers, and featuring at the center of all ember applications, a router! A router is a piece of code that takes in a request and decides what code to run as a result. That is eerily similar to what’s at the center of all Rails applications. ! Hmm. ! This concept, that the incoming routes determine what code gets called, comes 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, then you are used to having much more control over what exactly happens to a request. So, Ember may feel a little…

http://www.flickr.com/photos/deanspic/4960440218 …overly constraining.

And finally we have Backbone.js — the old-school choice. Backbone was graduated out of a Rails app in the 2008-2009 timeframe. 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 will feel natural. Easy. Straightforward. Maybe not convenient, at times, but certainly understandable.

On the other hand, 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 flows from the type of projects you’ve done, rather than the technologies you’ve done them in. And that’s interesting! !

http://www.flickr.com/photos/gsfc/4690804595 What we’re seeing is that accessibility judgements come from many different sources when we’re talking about frameworks, because of the extra complexity over a simple gem. ! One source is the technology stacks you’ve worked with. Another source is the type of projects you’ve done. It’s also affected by who you’ve worked with, the industries you’ve worked in, and so on.

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

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

http://www.flickr.com/photos/seattlemunicipalarchives/2713475713 What they’re actually doing is turning the way they think into code. ! So…how do you see that? Besides, I suppose, coming here and reading my 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. 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. ! And remember that even once you’re explicitly thinking about accessibility, it may not always be the most important factor in your decision.

Popularity Interface Activity Accessibility Internal External Project People 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. But other times, your team is ready and willing to be pushed further. ! Sometimes you want popularity because you know you’ll need to hire 5 people and the timeframe is short. But other times you pick something totally unpopular & new because it has that one feature that you need for your project. ! When you’re making a decision, just make sure you’re actually considering all four quadrants.

of OH, HACKER NEWS… https://twitter.com/steveklabnik/status/444147360856551424 I want to close with something I saw on Hacker News last week. Steve Klabnik reads Hacker News so I don’t have to. (Thank you, Steve.) ! The context for this tweet is a blog post about Nimrod, an obscure programming language. And one of the commenters on Hacker News 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. ! I actually really sympathize with his point of view.

Popularity Interface Activity Accessibility Internal External Project People Because I thought that way when I was a new programmer. The decisions that other people make really do look mysterious if you think that the interface is all there is to consider when you’re evaluating a technology. ! Nimrod is failing to catch on. But not because people are illogical.

“A change in perspective is worth 80 IQ points.” Alan Kay http://www.flickr.com/photos/alexschwab/9205086243 It’s failing to catch on because their logic extends further than that guy can see… from down there. ! So, ok fine, 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 large-scale technical decisions. ! As a very wise man once said, “a change in perspective is worth 80 IQ points.” Alan Kay just invented object-oriented programming, that’s all. ! And I’d say with the things we’re thinking about - a change in perspective is worth 80 IQ points, and also 5 years of experience. !

of Sarah Mei [email protected] @sarahmei Thank you very much. This is my consulting company, and, of course, I’m writing a book.

http://practicalrailsbook.com I’m trying to make sure no one can ever tell me and Sandi Metz apart (two-syllable first name starting with S, one-syllable last name starting with M). ! So we are writing a book together. Of course she’s the marquee name. It’s about refactoring large rails apps. Go check it out at http://practicalrailsbook.com if that is relevant to your interests. ! Thanks!

Most photo credits are inline. Others: • Slides 1 & 2: http://www.flickr.com/photos/loop_oh/4621885147/ • Slide 62: http://www.ministryofvelocity.com/ • Slide 63: http://practicalrailsbook.com ! ALL THE LOGOS • Ember logo (slides 5, 10, 40, 48, and 50): http://emberjs.com/ • jQuery logo (slide 6): http://jquery.org/ • Angular logo (slides 7, 10, 40, 46): http://angularjs.org/ • Backbone logo (slides 8, 10, 40, 52, 53): http://backbonejs.org/ • Other logos from slides 10 and 40: • 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