Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Unpacking Technical Decisions - Mountain West Ruby Conf 2014

sarahmei
March 20, 2014

Unpacking Technical Decisions - Mountain West Ruby Conf 2014

As engineers working on a team, we all make technical decisions. What’s the best way to implement this? Where should this function live? Is this library worth using? Some decisions, though, are larger, riskier and more important than that. But generally, they’re also far less frequent.
Right now, your team might be struggling to organize the client-side parts of your application. Ember? Angular? Backbone? Flip a coin? Uh…which one has the most…retweets? These choices don’t need to be arbitrary or based on vague personal preference. Come learn a more useful and realistic approach that makes large-scale technical decisions less risky.

sarahmei

March 20, 2014
Tweet

More Decks by sarahmei

Other Decks in Programming

Transcript

  1. 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:

    View Slide

  2. 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:

    View Slide

  3. 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.

    View Slide

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

    View Slide

  5. 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.

    View Slide

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

    View Slide

  7. 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.

    View Slide

  8. 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:

    View Slide

  9. 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…

    View Slide

  10. 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.

    View Slide

  11. 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.

    View Slide

  12. 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…

    View Slide

  13. 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…

    View Slide

  14. 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.

    View Slide

  15. 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.

    View Slide

  16. 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?”

    View Slide

  17. 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.

    View Slide

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

    View Slide

  19. 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.

    View Slide

  20. 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.

    View Slide

  21. 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.

    View Slide

  22. 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.

    View Slide

  23. 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:

    View Slide

  24. 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.

    View Slide

  25. 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.

    View Slide

  26. 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.

    View Slide

  27. 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.

    View Slide

  28. 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.

    View Slide

  29. 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.

    View Slide

  30. 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?

    View Slide

  31. 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?

    View Slide

  32. 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.

    View Slide

  33. 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.

    View Slide

  34. 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.

    View Slide

  35. 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.

    View Slide

  36. 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.

    View Slide

  37. 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”?)

    View Slide

  38. 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.

    View Slide

  39. 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.

    View Slide

  40. 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.

    View Slide

  41. 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.

    View Slide


  42. View Slide

  43. 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.

    View Slide

  44. 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.

    View Slide

  45. 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.

    View Slide

  46. 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.

    View Slide

  47. 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.

    View Slide

  48. 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.

    View Slide

  49. 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.

    View Slide

  50. 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.
    !

    View Slide

  51. 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.

    View Slide

  52. 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.

    View Slide

  53. 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…

    View Slide

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

    View Slide

  55. 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.

    View Slide

  56. 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!
    !

    View Slide

  57. 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.

    View Slide

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

    View Slide

  59. 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.

    View Slide

  60. 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.

    View Slide

  61. 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.

    View Slide

  62. 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.

    View Slide

  63. 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.

    View Slide

  64. “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.
    !

    View Slide

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

    View Slide

  66. 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!

    View Slide

  67. 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

    View Slide