Launching Trajectory: Communication Builds Better Software

Over the past 8 years, we’ve used many tools for project communication and planning and we tried very hard to not write our own. The latest combination was Basecamp and Pivotal Tracker. Basecamp was great for discussion and communication. Pivotal Tracker was great for user stories and emergent planning.

However, we’ve grown tired of having one tool that designers love, one tool that developers love, and no tool that clients love.

I’m excited to take the lid off of our newest product, Trajectory.

Trajectory is an agile planning tool that helps teams discuss and plan their projects in a realistic, structured way.

We set out last summer to create something which met the following goals:

• Encourage conversation. The ability to start with a feature idea, and have a real conversation that defines exactly what to build and results in a story that describes what that is.
• Embody a clear workflow. A better system for people to know exactly what to work on next and do so in a way that designers, developers and clients all agree makes sense.
• Look and work great. Be easy to understand, embrace workflow and linkability, and be enjoyable to use.
• Track velocity and have emergent iterations.  A way for all team members to know where things really stand, and what momentum looks like.

We created Trajectory to solve our own problems. We now use it on all of our projects. Maybe it can solve your problems too. I invite you to learn more and give it a try for free today. If you’re currently using Pivotal Tracker, you can import your project and get up and running in a matter of minutes.

Many thanks to all the designers and developers at thoughtbot who have worked on this since last summer’s CapeCo.de, our clients who were the early, enthusiastic alpha testers, and our designer and developer friends who have helped us work through bugs and add polish in the last few weeks.

A safer apprenticeship than Johnny Tremain’s

Announcing the new Apprentice program at thoughtbot

We’re looking for both designers and developers who are students, recent graduates, or more experienced candidates making a techology or career change to come on as Apprentices. If you are interested in applying, please visit our jobs page. If you know someone who might be a good fit, please pass it on.

The paid apprenticeship lasts for three months and during that apprentices will work alongside members of the thoughtbot team on actual shipping software and be paired up with individual developers and designers at thoughbot who will act as their mentor. They also get to take any workshops we offer during their apprenticeship at no charge.

At the end of the apprenticeship we may offer them a position as a web designer or developer at thoughtbot.

How the Appentice program came about

We’ve had interns, particularly in the summer, for several years now. Over the past few years we’ve increasingly been contacted by more experienced developers who are just getting started with Ruby and looking to find a place where they can be effective, while still learning.

At thoughtbot, we also don’t have different levels of developers or designers.  Everyone should essentially be capable of operating at the level of senior developer or designer (or be able to soon after starting). We do this to ensure that we can operate effectively without project managers or salespeople.  However, from time to time we interview people who we think may be a good fit eventually, but need more experience. In the past, we’ve sometimes offered these people an internship as a chance to learn on the job and potentially quickly grow into the developer we need them to be.

When offering these people an internship, it never quite felt right to call them “interns” but it was the best word we had.  Additionally, over time we refined the internship program to really be a path to potentially getting an offer to be a full web designer or developer at thoughtbot.

With this in mind, along with some other lesson’s learned from the previous interns, we sought to have a more structured program in place. Out of that emerged our new Apprentice program.

We think that the changes we’re making now should make the Apprentice program worthwhile to everyone involved, and we’re looking forward to the first batch of Apprentices joining us in May.

A shortage of developers

If we were in China, would the govt mandate the creation of 100K Ruby developers? This shortage is killing us. - Jeffrey Bussgang, VC at Flybridge Capital Partners

Demand for developers and designers at web startups is currently outstripping supply.

I believe this is true because most of thoughtbot’s clients are web startups. Most of my programming buddies along the Red Line in Boston/Cambridge work at, or for, web startups.

Widespread Panic

If you are a good software engineer, you must move to Silicon Valley. I’ve never before seen such an intense war for talent. Engineers win. - Chi-Hua Chien, VC at Kleiner Perkins

I’m not really tuned in to the subcultures in SOMA, San Francisco or Union Square, New York City but folks there seem to telling the same story.

Down With Disease

Considering that the Ruby Community is a group of “doers” – bitching without proposing a solution is weak sauce. - Randall Thomas, good dude at EngineYard

So there’s a shortage (and let’s be honest: we’re short a few thousand developers, not a few million potatoes, so in the grand scheme of things, we’re actually riding the gravy train).

I think there’s a simple solution: Make more developers.

I can think of three ways to do this, and thoughtbot is trying all three:

1. Teach high school and college students.
2. Teach enterprise/.NET/Java/PHP/Coldfusion developers new tools.
3. Convert non-technical founders to technical founders.

Give that Boy a Hand

First, thoughtbot partnered with Greenhorn Connect to organize a free event for 300+ high school and college students called Developers Developers Developers Developers. It was held last week, a good time for them to start looking for a full-time job or a summer internship.

The event was a welcome wagon for students into the web community. Folks from places such as Github, GroupMe, Heroku, ITA Software, and Swipely gave rip-roaring talks.

The man himself, John Resig, was there, talking about jQuery and jQuery Mobile. He also hammered home a couple of important messages:

• Startups are cool and all, but you can contribute to open source no matter what your company looks like, or even if you don’t have a job at all.
• Your Github account is a great resume.

Cissy Strut

Second, thoughtbot partnered with Fairhaven Capital to offer Ruby on Rails workshops to local developers who are currently working in .NET, Coldfusion, or PHP. The cool part is that Fairhaven is covering 50% of the cost of the training (usually $1,256) to lower the barrier for developers to make a technology switch.

In addition to doing something nice for Boston, they’re subsidizing accelerated learning. Intensive training can help people learn months faster than they would otherwise.

If you’re interested in attending, you can apply here.

The Word

Third, I’ve been telling non-technical founders that “everybody codes”. I’d like the class of “non-technical” founders to be “non-existent.” If a startup wants to want to hire us, I think there’s a higher chance of success if one of the founders commits to learning to code by pair programming with us on their product.

Consider the alternative of a young web company without a technical co-founder. They’re doing some combination of:

• hiring someone else
• looking for a co-founder
• learning to do it theselves

I’m thinking the best of all worlds is to hire a firm like thoughtbot to build initial iterations of the product while the “non-technical” co-founders learn how to do it themselves from experts, on their own product that they care about.

This model should work because:

• Something high quality gets built immediately.
• Less time is wasted trying to find someone in a competitive market.
• Founders control their own destiny after the engagement.

We’ve called a similar approach Kick Start in the past, but geared it more towards interviewing and giving hiring recommendations. I don’t think that’s good enough anymore. The founders can’t keep hiring “other people”. A web development firm working with startups should be moving the founding team toward self-sustainability.

Ain’t Nothing Wrong With That

The three strategies we’re trying are all experimental. They all depend on collaboration. Hopefully, some of them will work and we’ll have some new buddies with whom we can identify problems and dream up solutions.

Design Driven Development

Most of my thoughts about design spawn from asking myself what makes a project successful. Well, what does? Most will agree that good design does. This is not speaking exclusively about the graphic design or implying that everything rests solely upon the shoulders of the Designer. Everyone is a designer. Design is a fundamental part of everything. Keep this philosophy in mind for the entirety of the project.

How we guide projects

thoughtbot has always been known primarily for its Rails expertise and as such the projects have been driven majorly by the development, headed by a Lead Developer.

Over the last year or so, with the addition of new designers to the team, we were able to focus much more on design. We’ve started with design first, as we should, and this has been quite successful. The general practice was to do our research, form our wireframes, and move onto the visual design. The problem is, once we got past the initial design steps our process would splinter a little. Design would still be important and never forgotten but a detachment formed between the design and the development.

Now, we want to fix this. We need to make sure that whatever we’re working on is the most beneficial thing to the end user. We work off user stories and shouldn’t pick ones to work on because they’re easy or need to get done eventually. The user stories should be prioritized with good design in mind. We must stay vigilant in creating the best possible product for the target audience. A great way to accomplish this is to keep the design of all things at the forefront of our thought processes. Keeping a project driven by design will help this happen.

The improved way

As of late we’re beginning to drive projects with design from start to finish. As I hinted at already, this does not mean a project should revolve around the graphic design or visual aspects. This means the design of everything should be well thought out. From things as simple as structuring the meetings well, to things as complex as building the code properly, to things as crucial as wireframing the flow of the app. Design should be at the forefront of our thoughts in every step of the building process.

Things to help improve

We’ve had great success with a few things lately. None of them are new ideas but sometimes we just forget about them. They are all things that both a designer and/or a developer can accomplish.

For early prototypes, faster and simpler is better than slower and more polished

Recently on one of our projects we wanted to test out a proposed flow for a new app. In a day or two we were able to bust out some very unsexy but very understandable HTML wireframes. They were clickable, buttons did what you expected them too, and you could navigate between pages. The app didn’t have any real functionality but it helped both the client and us easily identify trouble spots and conversely figure out what was working best. This was immensely helpful and saved quite a bit of time in the long run.

User test early, refine, user test again

On another recent project we wanted to get something in front of people as early as possible. Similar to the wireframes in the last section, the app did not work. It was a little more polished but really just a pretty wireframe. The difference between this and the previous method was the people running through the app were not part of the team. Even having a few people unfamiliar with the app click through and share immediate thoughts let us rapidly modify the app and only a week later, test again. Over the course of 5 weeks we did this 3 times. The client is pleased (and enjoyed listening to the feedback) and the app is undoubtedly in better shape than it would have been if we waited longer to user test.

Keeping designers, developers, and clients connected

One of the biggest problems, in my opinion, is having the design and development relationship splinter as the project grows, both roles will just work on what they feel is best without consulting one another.

There are a few things you can do to help avoid this. The biggest aid, in my opinion, is designers, developers, and clients work physically close to each other. Members of teams at thoughtbot all sit together, and we’ve undeniably had our best results when the client was able to work with us in person. We can easily verbally communicate at a moments notice. We’ve found that asking user and goal related questions, discussing as a team, and coming up with the best solutions really helps to keep us on track and work as one unit. Questions like:

• Who are the users?
• What are the primary goals for the users to accomplish?
• What things need to happen in order for the users to perform these actions?

Try it out

To facilitate these ideas, whoever is best fitted and most comfortable to fill a role that focuses on designing for the user experience should be the project lead. This can be a designer or a developer. Everyone is a designer. Everyone helps the design process. So, if you haven’t tried this process yet, give it a shot on your next project. Embrace well thought out design in all aspects of your project, and see if you don’t feel better about the end result.

Sgn up, sign in, sign out

What is your Ubiquitous Language for authentication?

Common language includes”logging in”, “registering”, “joining up”, “creating an account”, “signing up”, and “signing out.”

Do you interchange these words in your UI? How about in your application code? Tests? Does your whole team use the same language across all layers of the software?

When writing a library like Clearance, I feel the authors should take a stand on language to alleviate the mental burden on designers, developers, and business analysts involved in the project.

The decision is basically arbitrary. No one set of terms is better than the other. What’s important is to take the opportunity to standardize all the places this shows up in code.

So we picked “sign up”, “sign in”, and “sign out”, a lingual trinity of authentication.

We liked the symmetry. We liked that there was less of a chance of writing “log in” (sounds like a verb) or “log_in” in certain places and “login” (sounds like a noun) other places.

About a half a year later and we still feel good about the effect.

Tests

context 'when signed out' do
  context 'on get to new' do
    setup do
      get :new
    end

    should_deny_access
  end
end

context 'when signed in' do
  setup do
    sign_in
  end

  context 'on get to new' do
    setup do
      get :new
    end

    ...
  end
end

context 'when signed in as an admin' do
  setup do
    sign_in_as create(:admin)
  end

  context 'on delete to destroy' do
    setup do
      delete :destroy
    end

    ...
  end
end

Application code

class UsersController < Clearance::UsersController
  def create
    ...
    sign_in(@user)
  end
end

class ParticipationsController < ApplicationController
  private

  def ensure_signed_in
    unless signed_in?
      store_location
      flash[:failure] = 'Please sign in to participate in this deal.'
      redirect_to sign_in_path
    end
  end
end

module NavigationHelper
  def authentication_links
    if signed_in?
      signed_in_links
    else
      signed_out_links
    end
  end

  def signed_out_links
    [link_to('Sign up', sign_up_path),
     link_to('Sign in', sign_in_path)]
  end

  def signed_in_links
    [link_to('My Account', edit_user_path(current_user)),
     link_to('Sign out', sign_out_path)]
  end
end

UI

For something as common as authentication, familiarity for users breeds comfort. So what do the others do?

Basecamp is a little inconsistent, mixing sign in with login:

Apple is pretty as usual:

Google is perfectly consistent. Youtube and Gmail:

Sweet, sweet consistency.

Written by Dan Croak.