00:00:29.960
I was here last year, and I did a talk last year, so I feel like I know half the room already. But in case I haven't met you, I'm Sarah, and I run a consulting company called Ministry of Velocity in San Francisco. I spend most of my days helping people refactor large codebases.
00:00:44.160
I wasn't supposed to be up here this year. I was on the Mountain West program committee, which meant I got to read all the proposals that people sent in. It was pretty cool, and I think we did a good job coming up with the program, right? Do you agree? It seems okay so far. However, as a program committee, there was one critical thing that we failed to do, and that is to have sufficient backup speakers. So that's why I'm here.
00:01:20.400
I'm actually really excited to be here. I did this talk last week at a conference called Fluent, which is a JavaScript, CSS, and HTML conference in San Francisco run by O'Reilly. Here's a picture of that conference, and you can tell it's an O'Reilly conference because they sprung for the expensive, no-flip name tags. Apparently, that's what the extra $600 in the ticket price gets you.
00:01:30.299
Fluent is not the type of conference I normally attend; I'm usually hanging out with Ruby developers, people who consider themselves either back-end developers or full-stack developers, which is a totally different crowd. I spent a lot of time at Fluent wandering around, talking to people, interrogating them, and making them tell me why they went there. The people I met fell into three categories.
00:02:01.560
First, there were back-end developers who were there to learn more about front-end development because all the cool kids are full-stack developers these days. There were visual UX people who were coming at front-end development from the other direction, and of course, the largest group consisted of front-end developers who were there to learn more about what they do.
00:02:34.500
What surprised me was that when I asked specifically why they were there, they all told me the same thing. Here are some quotes that might sound familiar: "My group has started an Ember project, so I'm going to every EmberJS talk on the schedule." "My web app has an old jQuery codebase, and I need to figure out what to do with it." "I want to learn about Angular; I think I can raise my rates." And finally, "We have an ancient Backbone.js setup, and we need to rewrite it in something cleaner." And by ancient, I think she meant like six months old.
00:02:58.060
What was interesting was that no matter what direction these people were coming from, they all had the same question on their minds: what JavaScript framework should I be using? I imagine this is how I look when I try to solve this problem, and this is one of the big open questions in web app development right now. How many of you in this room are thinking about that as part of your work? Right, like everyone is thinking about it. It's an open question because there's so many options.
00:03:31.080
Unfortunately, even though it seems like we have some front runners emerging, it's still really early. I mean, Ionic, which is in the upper left corner there, just got a million dollars in funding last week. So, very early days, very confusing.
00:04:03.060
Every technical community has questions like this. These are things that everyone is writing about, and they really want to tell you their opinions on. For example, one of the other questions that we as Rubyists have at the moment is, what datastore should I be using? PostgreSQL or Cassandra? So many choices! And when you're a developer with a specific project in mind, it can be hard to tell what the right answer is.
00:04:24.600
The internet has a ton of information about this stuff, but unfortunately, it’s really hard to sift through and find the things that are useful. Here's a fun fact: if you Google how to pick a JavaScript framework, as of last week there were two pages of results for the last six months. Unfortunately, all of these things, taken together, are about as helpful as a collection of parking signs. I want you to look at that and tell me whether you can park there at noon on a Tuesday.
00:05:00.060
These blog posts and discussions give you contradictory and confusing information. That was the case even at Fluent. I would go to one talk that said, "Ember is so amazing for X," and then in the same room, the next time slot was an Angular talk that argued, "Angular is clearly superior for X." And your job is to synthesize all of this data into a decision—no pressure, right? But it's really important because the cost of being wrong is high.
00:05:59.459
It's not just that you might be parking illegally and get a $30 ticket. It’s like if you pick a JavaScript framework that isn’t suited to your project, it can be quite disastrous depending on when you realize it. How far down the road do you have to go before you find out that there’s no more road?
00:06:46.339
These decisions are big, and they're 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 brains to learn is by repetition. You may have heard the popular meme in programming culture: it takes 10,000 hours of practice to become great at something, whether it's playing an instrument, programming, or whatever.
00:07:14.640
It's an oversimplification of how people learn. The repetition is powerful; however, the key is not just time spent, but how you spend that time. You can spend 10,000 hours on something, but if you’re not doing it right, those hours are wasted. To learn by repetition, you have to do the action, analyze the outcome, and then repeat the action, changing it a little bit each time. That’s how you find out what works.
00:07:56.760
If you could wait 10 or 15 years to accumulate more experience with decision-making, that would be ideal. But we can make an end run around this limitation by analyzing the decisions we do make all the time and bringing that intelligence back to the framework choice. Our decision-making happens at different scales and frequencies.
00:08:16.200
Language and framework choices are the most infrequently made decisions, but there are a few things we do more frequently—like deciding whether to use some random code you found on GitHub. Even more frequently, we make technical decisions every day about things like where this code goes, what I should call this variable, or whether I should write a test now.
00:08:41.220
But even at the smallest, most frequent level, the process we use to make these decisions is pretty opaque. If you ask a programmer why they named a variable a certain way or why they put a function where they put it, often the best answer they can give you is, "It seemed like the right thing to do." Sometimes you get answers like "experience," "intuition," or "gut feeling." When I ask one programmer why they like Ember over Angular or vice versa, I get similarly opaque responses.
00:09:02.160
That led me to investigate what goes into that feeling—what data we collect and how we organize it. I aimed to get insights into these evaluations. It turns out that we all know people who evaluate random code off GitHub, and I asked a bunch of my colleagues to introspect for me and describe how they evaluated a gem they were considering for their project.
00:09:30.780
Everyone starts in the same place: they go to GitHub and read the README. This README actually predates GitHub; it's from 1936 and is about how to operate a telephone. When people come to a README, they're looking for features, functionality, and usage of the code they're examining. This information is usually easy to find because it's often presented in bullet points.
00:10:11.160
Now, let’s consider an example evaluation and walk through what this looks like. Let’s say you're trying to pick a gem to make HTTP requests. We all know that making HTTP requests is key to using the internet, so we do some Googling and find two contenders: HTTP Party and Faraday.
00:10:40.320
Assuming you don’t dismiss HTTP Party just because you don't like saying it, you can look at the README and the usage section. You find that HTTP Party has static methods you can call, or you can include its module into your own object. Faraday, on the other hand, provides a connection object for making calls. Both interfaces will allow you to make any HTTP call you need.
00:11:06.120
However, this information alone is not enough to make a decision. Similarly, the bullet list of features of a framework isn’t enough to tell you whether it’s worth using. So what else do we consider?
00:11:30.000
From interviews with various people, I found that everyone pretty much starts by looking at the GitHub README. After that, they look at the frequency and recency of commits, the number of issues and how old they are, comments to see if the maintainer is active, the number of recent blog posts, and they even check Ruby Toolbox to compare how a gem stacks against similar gems.
00:12:10.740
They check the date of the last release, look at Stack Overflow to see how many questions are asked about it, how many of those questions are unanswered, and ask colleagues for their opinions. They consult Twitter, Hacker News, other developers, and often look for screencasts. Sometimes they read the code directly or build a sample application around it. This is not an exhaustive list, but it's practically everything my informants mentioned.
00:12:42.240
Different people rank these evaluation methods differently. Everyone seems to start poking around on GitHub, and some individuals ask their colleagues for input right after that. One person I spoke to works at a place where displaying ignorance is frowned upon, so he heads straight for the official documentation. No one does all of these evaluations for any given gem, but the riskier the decision is, the more of these evaluations we do.
00:13:24.300
Furthermore, this list changes as the community that generates it evolves. For instance, before Rails, a lot of discussion about Ruby libraries occurred on the official Ruby mailing list; now it doesn't. Each community has its own list of what to evaluate. For example, if we were to gather an equivalent list for Python, we'd likely get more mailing lists included because that community relies heavily on mailing lists.
00:14:01.740
So the way we collect and use this data is pretty complicated. Interestingly, though, if you evaluate this list, most of it is not about technical data. We imagine evaluating code involves scrutinizing the code, leading us to believe we base decisions on technical factors, but most of this data is actually social. It has to do with the people around a project—the maintainers, the users.
00:14:37.620
Some technical data is included, such as the interface of the gem or library, which is about its functionality. The other information tracks the activity level of the project—how frequently it is updated, and whether you'll get help from a maintainer or have your pull request merged. You'll find that much of the information available during evaluation concerns the popularity of the project among developers. This influences how easily you'll find help if you run into problems.
00:15:17.500
This leaves us with a couple of outliers—reading the code and reading the tests—elements that don't quite fit within the previous groups. While interface, activity, and popularity provide straightforward sources of data, reading the code and tests is fuzzier. These address the familiarity of the code—whether it feels idiomatic for Ruby, if the maintainer matches my testing strategy, or how similar this code is to what I would write.
00:15:56.613
Thus, I want to label this category "accessibility." There are four central categories of data we consider when deciding about a gem: interface, activity, popularity, and accessibility. Once I reached this point in the presentation, I realized these can be grouped in two different ways.
00:16:38.520
We can categorize accessibility and interface, both regarding whether the project meets your needs on a personal level: is the code doing everything you require? This stands in contrast to popularity and activity, which focus on the external factors. In this manner, we can derive an internal perspective from both accessibility and popularity.
00:17:14.760
We can also review the way activity is influenced by the people involved in the project and realize that the conduct of its community members affects usability and accessibility. I shared this framework when I showed this talk to a friend, who remarked that consultants are supposed to have systems they're marketing. Now I have one! It’s a more targeted approach to navigating decisions regarding languages and frameworks.
00:18:01.020
We can give it a name, and I'm going to name it the "Main System"—that sounds narcissistic, but here we are. If that title entices you to throw lots of money at me, then please do so; otherwise, I’ll stick to my pairing programming approach for now.
00:18:41.500
What we have done so far is capture what people actually do and categorize it. While this is valuable, it truly becomes powerful once we apply these categories to higher-risk decisions. In these decisive moments, the method of employing these evaluations can influence outcomes significantly.
00:19:22.860
Let’s take another look at interface, which signifies the ease, convenience, and overall appeal of a framework. To make a solid choice between frameworks, we must examine the accompanying activity levels of the projects at hand.
00:20:00.140
We also consider the popularity level, calculated through various factors, including content and arguments posted to Stack Overflow. The accessibility of all these frameworks could hugely impact the experience as well. For instance, we could explore how far along a developer comes in understanding the intricacies of various frameworks.
00:20:35.700
Now let’s draw back to early Java and JavaScript interactions, which haven’t always been positive. Historically, Java web framework land has been a sad place for JavaScript developers due to the Java Community dedicating considerable effort to sidestep JavaScript entirely.
00:21:24.420
In recent times, AngularJS emerged as a contender written by Java developers, embodying a structure reminiscent of modern Java back-end frameworks. This makes it feel familiar and accessible to those hailing from such backgrounds. However, it's to remember that developers who have primarily dealt with Java or .NET might have more difficulty adapting.
00:22:00.360
On the flip side, those of us who didn’t come from those backgrounds may find the dependency injection in Angular more disorienting until we adapt, making its adoption riskier. Finding a framework that aligns with existing thought processes leads to a smoother transition and reduced risks.
00:22:41.220
Let’s look at the newer frameworks more closely—including EmberJS, which was built for Rails developers. It has a router at its heart which closely parallels what's found in Rails applications. Thus, if you come from a RESTful background, Ember feels natural and accessible.
00:23:14.380
Backbone.js represents the granddaddy of these frameworks. Born out of a Ruby on Rails app, it can be likened to existing server-rendered pages. In this case, Backbone feels intuitive if you still think of web applications as server-rendered counterparts.
00:23:50.660
However, for more modern developers who view web applications through a JavaScript-first lens, Backbone seems outdated and counter-intuitive. Therefore, the accessibility judgment here shifts based on past project experiences.
00:24:21.820
Accessibility judgments emerge from various sources when evaluating frameworks, chiefly owing to the increased complexity of frameworks versus simpler libraries or technologies. Accessibility can encompass influences like technology stacks and project types you've previously managed, along with influences from people you've collaborated with.
00:25:04.140
However, determining accessibility can be quite challenging since it is often not out in the open. Framework creators assume their work is designed for everyone while neglecting the reality that it is primarily an interpretation of their logic.
00:25:38.280
Notably, logic informs the perceptions of the framework's utility and familiarity to its users. What remains significant is the comfort or discomfort experienced with a particular framework. These feelings express how well a framework aligns with personal work styles and team familiarity.
00:26:12.460
When faced with implementing a new technology, it’s critical to remember the four quadrants we’ve outlined—they may impact decisions about team resources and approaches. In situations where teams are ready but overtaxed, selecting a solution that closely matches familiarity may be a priority.
00:26:56.820
In other circumstances, teams might feel more ambitious, seeking popularity for assurance of future hiring potential. Ultimately, remember all four quadrants when making a decision.
00:27:31.700
To close, I read something on Hacker News last week, and Steve Klabnik reads Hacker News so I don't have to. The context was a blog post on Nimrod, an obscure programming language. One commenter expressed frustration regarding Nimrod's lack of popularity, arguing that people don't evaluate tools logically. In a sense, he was right, but only partially, as people's logic often encompasses more than he acknowledges when evaluating technologies.
00:28:27.000
Although we can't repeat language or framework decisions often enough to learn through repetition, we can take these categories to expand our perspectives when considering large-scale technical decisions. As a wise man once said, changing your perspective is worth 80 IQ points.
00:28:56.060
And with reference to these discussions, I’d assert that your changed perspective can render years of experience worth just as much.
00:29:09.359
Lastly, I'm also trying to ensure that no one will confuse me with Sandy Metz, so we're writing a book together about how to refactor large Rails apps. If you're interested, check out practicalrailsbook.com. Thank you!
