Causes Engineering

Recently, Joe and I have been doing some performance work on causes.com to speed up the time it takes to generate a page on the server. Most of that work meant reducing the number of database queries we make. Take the profile page for example. On that page, we list the most important campaigns you’ve participated in. Before we started optimizing it, we were making more than 10 queries per campaign listed. We added some pre-loading and caching and managed to take all those database queries down by 90%. That in turn brought the time it took to generate this page down from about a second to 200 milliseconds.

Are you worried that your CSS changes will break the current design in unexpected ways? Do you want to show a designer a page you’ve been working on, before and after your changes? Do you want to be able to quickly look back at how things looked a month or a year ago?

Diffux [dɪˈfjuːz] is a tool that generates and manages visual diffs of web pages, so that you can easily see even the subtlest effects of your code modifications.

Sally has been tasked with making the commenting feature in her company’s webapp be threaded up to 5 levels instead of only 2 levels. As she makes adjustments to the code, she collects an unprecedented number of browser tabs. Some of them point at her company’s production site, while others point at her development environment. In many of them, she enabled “super-user” mode, so she could more freely play with her app while making her changes.

So she goes on coding and messing with the data for most of the afternoon. She’s about ready to wrap up and head home for the evening when her boss walks in and asks, “Sally, lots of comments have gone missing. Do you know what happened?” Sally felt like she had swallowed a sack of doorknobs. In the midst of her coding spree, she mixed up some of her browser tabs and accidentally deleted live data. A lot of live data.

We tend to prefer convention over configuration, so when we first began using Bower to manage our front-end dependencies, we started with minimal configuration. While this nicely put the files in the expected places, it was a hassle actually using the assets in our Rails app.

Our basic initial approach was to symlink the assets that we wanted to reference from the bower_components directory into vendor/assets where Sprockets would notice them. While this worked in the short term, it was tedious to set up new packages, and was likely to break if the required assets were moved when upgrading dependencies.

Ultimately, this felt like a hack. We decided that there must be a better way. Thankfully there is.

A mobile-first approach to design can be good: it helps you focus and potentially simplify your requirements, which can translate into a better user experience. Likewise, a mobile-first approach to implementation can be good: it puts the more expensive tasks on the shoulders of clients that are more likely to be able to handle the extra load, which can also translate to a better user experience.

At Causes, we have been building things with a mobile-first approach both in terms of design and implementation with a goal of progressive enhancement. Since switching to this mode on the technical side, we have noticed that our code is easier to write and more coherent to read, both of which are big benefits for the engineering team.

So we’ve put together a little project that helps us write readable media queries in this way. We call it sass-enhance.

“How fast are your tests?”. Have you ever had that question? Probably not. Does performance matter for tests? Yes, and here’s why: The time it takes from you changing a bit of code until you get feedback on whether or not that code works is crucial in knowing if your code is good or not. Let me illustrate by two scenarios.

Giving structure to an agile engineering team is hard. You want people to work on the things that they are most interested in without losing focus on the main goal of building a great product. No matter how you split your organization into teams, you will miss covering certain areas of interest. This is where working groups can come into play.

I recently had an experience I expect is common for designers who work at startups: I presented a well-polished mockup to a key stakeholder late in the design phase of a project and he told me flat out that the design didn’t address his users’ needs. This, after I’d met with him twice before.

This was my first project at my new company and I was still getting to know everybody and their roles, but excuses aside, I quickly realized this happened because my team never got our business stakeholders together at the beginning of the project. Because we didn’t make time to discuss the problem we were trying to solve, everybody was operating under their own assumptions. If we were going to improve communication on our next project, my product manager and I needed to discuss how to set expectations about our design process; we needed to be more intentional about when we got feedback from which groups of stakeholders, and what kind of feedback we were seeking from each group. If we were successful, we’d be able to get consensus quicker and reduce iterations needed to get to a solution that was ready to be specced.

In object-oriented code, there are several choices for where to put a new function, and each choice has its pros and cons. These choices repeat themselves over and over in a codebase, so it’s worth reviewing the tradeoffs we make on a daily basis.

Over time, large-scale object-oriented systems tend to produce God Objects. These are classes which know too much or do too much. They have connections to disparate and varied parts of the system. They depend on everything, and everything depends on them. They make systems slow to work with, intractable and hard to modify. They insidiously undermine and resist our efforts to carry out our core task as engineers: decomposing complex problems into smaller subproblems that are more easily solved.

At Causes there are some concepts that are front-and-center in our product: users, their campaigns and the actions they create to make an impact (things like petitions, fundraisers and pledges). The concepts are so core that they have a tendency to become God Objects unless we diligently work to prevent them accruing more and more functionality.

We’ve lately applied the Pub-Sub (Publish-Subscribe) model to our Ruby code, applying the familiar event-based patterns that we know from JavaScript to the server side, in an effort to reduce the tight coupling that some of these God Objects have to other parts of the system. With a simple, framework-agnostic Ruby library, we’ve been able to significantly tame some of the complexity around these classes, and we’ve released it as a Ruby gem, PubSubHub.