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

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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 -

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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

View Slide

•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:

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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:

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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…

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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

View Slide

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.

View Slide

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?

View Slide

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.

View Slide

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

View Slide

•Interface
Let’s consider an example evaluation. Let’s say you’re
trying to pick a ruby package (called a “gem”) to make
HTTP requests.

View Slide

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.

View Slide

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.

View Slide

DevMynd
HTTPARTY
FARADAY
INTERFACE
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.

View Slide

DevMynd
HTTPARTY
FARADAY
INTERFACE
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:

View Slide

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.

View Slide

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

View Slide

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

View Slide

DevMynd
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 deﬁnitely include some
mailing lists.

View Slide

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

View Slide

DevMynd
Interface
README,
use gem
EVALUATION
The ﬁrst 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 ﬁrst. 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.

View Slide

DevMynd
Activity
Commits, issues, PRs,
releases, docs
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.

View Slide

DevMynd
Popularity
SO, HN, Google
EVALUATION
Interface
README,
use gem
Activity
releases, docs
These things are information about the project's
Popularity among other developers. How easy will it be
to ﬁnd help when I run into a problem? Can I hire
someone? How likely is it that someone else has already
ﬁxed 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.

View Slide

DevMynd
Accessibility
Look at code
EVALUATION
Interface
README,
use gem
Activity
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.

View Slide

DevMynd
Accessibility
Look at code
EVALUATION
Interface
README,
use gem
Activity
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.

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

DevMynd
HTTPARTY
FARADAY
Add http call
functionality
to your object
Keep http
functionality in a
separate object
INTERFACE
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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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

View Slide

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

View Slide

Unpacking Technical Decisions - NDC London 2014

Unpacking Technical Decisions - NDC London 2014

sarahmei

More Decks by sarahmei

Other Decks in Technology

Featured

Transcript