Every Two Weeks

Our most popular gems—paperclip, capybara-webkit, factory_girl, and clearance—will see new releases every two weeks.

Trying to be reasonable

Release early, release often. In the past we’ve often released new versions of gems in a “when we feel like it” fashion: either we needed the gem to exist for a personal project, or we’re proud of some change we just made, or someone complained to us about an old version. This lead to a problem: when we were just taking pull requests we didn’t think to release a new version.

By setting up a regular schedule this means that contributions will be more public more quickly. We chose two week cycles as a compromise between releasing very often (every time we take a pull request) and in a wide duration (every three months). Too often and we’d annoy people when they upgrade; too infrequently and the bugs are simply not being fixed for the largest number of people.

It’s a process

Setting aside time to make a release elevates it from “OK I made these changes gem push woo!” to “I am going to make a proper release”—it reifies the release as a first-class action for us to concentrate on. Changelogs, blog posts, and tweets are side effects of putting the right amount of care into releasing a new version of a gem.

When‽

Factory Girl (factory_girl and factory_girl_rails) and Paperclip are on a two week release cycle starting January 27th, 2012. Clearance and capybara-webkit are on a two week release cycle starting February 3rd, 2012.

You can track gem releases using the RubyGems Web site and your favorite feed reader. It’s like this:

1. Sign up for RubyGems, or sign in if you already have an account.
2. Navigate to the page for the gem you care about.
3. Click “Subscribe”.
4. Click the “Dashboard” link at the top of the Web page.
5. There’s a sweet orange RSS icon in the middle of that page. Subscribe to that link!

When you say “every two weeks”…

Sometimes it doesn’t make sense to cut a release only every two weeks. Important security fixes or bugs that block everyone from using the gem are examples where getting something out as soon as possible is the only way to do it. On the other hand, sometimes there simply haven’t been any changes.

If we release a new version of a gem on the 26th and the 27th is when a scheduled release is to happen, it’s likely that we’ll skip the schedule. In general we’ll continue the “do I feel like making a release?” thought process, but every two weeks and with a bias towards a positive answer.

Or whenever

The bi-weekly cycle is new and, like everything else in software and life, worth reconsidering at all times. Please let us know if it’s too often, too seldom, just right, or completely useless to you!

From the desk of a thoughtbot apprentice

First, let me introduce myself, my name is Alex and I’m an apprentice here at thoughtbot. You may recognize me from this, this or this.

As an apprentice I get to immerse myself in the world of thoughtbot. I sit next to amazing developers and designers, and do work on the exciting projects that come through the door. As a result I’m learning crazy fast, every day I write code that I could not have written the day before. However, even bigger than the knowledge I’m gaining about how to write code is what I’m learning about process of developing software. One of the things that’s really important is the way people work.

I had heard words like XP, agile, and scrum used to describe software development but had never seen them in practice. After 5-plus weeks here I can tell you that the way they do things works.

Standup

Every morning at 10:00 am the entire team gathers in the conference room. We each go around the room and say something along the lines of the following:

Alex: Yesterday I worked on ______, I implemented ______ I had to do ______ to make it work. Today I will be working on ______. I am blocked on ___________.

Someone else: Yesterday I worked on ______, I did ______. Today I will be working on ______. I have no blockers.

These standups are the lifeblood of thoughtbot. They improve communication internally and provide accountability. If I say I’m gonna do something in standup then I do it. It ensures that if someone is blocked on a problem that someone else can solve, then that problem gets solved.

Retrospectives and teams

We work in teams. Each team usually consists of one designer and 2 to 3 developers. Each team dedicates its time to one project. Once a week each team meets with the client to discuss what was done during the week. As part of the retrospective each person on the team as well as the client goes around the table describing how they are feeling about the project and airing any grievances they may have about the way the project is progressing. These meetings make sure that the team is all on the same page and that we are doing work that our clients approve of.

Airing of grievances

Client Pitches/Caring about what we’re working on

Before we work with a client we ask them to pitch to and converse with the developers and designers (not just the management) on their product. We want to know:

• What’s their business model?
• Who are their competitors?
• Why is it a good idea?
• Will they be fun to work with?
• Do they get the principle of an MVP?

The reason we do this is simple. People do better work on projects that they’re excited about. By having potential clients pitch the product to us we can choose products that we want to work on.

TDD

Before I started at thoughtbot I was of the opinion, like many others, that testing your code is a waste of time.

It was part of my job as an apprentice so I did it. But I was not as exuberant about it as most of the other people here.

But then something changed.

I began to write cleaner code that solved real problems and when code introduced breakages I knew about it right away. 

Now I get scared when I see code without tests and I am test driving all my code, even the stuff I work on outside of thoughtbot.

Trajectory

We practice what we preach and use Trajectory to manage product development. What this means is that there are no emergencies. If a client finds a bug or needs a feature developed, they simply put it in Trajectory and prioritize it. The developers and designers are able to take the top story off the stack and have a discussion around it. All from within the app.

Campfire

We use Campfire extensively. We have a bunch of rooms:

• General Discussion, for company wide news, blog posts, etc.
• Dev Discussion, filled with vim tips, bugs and other geeky goodness.
• Design Discussion, I have no idea what goes on in here but it involves designers.
• A room for each project, in these rooms we post feature branch code reviews as well as project specific questions.
• Last but not least is everyone’s favorite room, Watercoolor (or WC, as we call it). You see images of people’s heads photoshopped onto other people’s bodies as well as other off topic discussions If any of the other rooms go off topic, someone, usually Mike Burns, will chime in with WC reminding us that the current chat belongs in the watercooler room.

These Campfire rooms provide a non interruptive internal dialogue. People can look into the room when they want to and ignore it when they’re busy coding (or designing).

Pace

One of my first days here, someone was explicitly told not to work on a client project on the weekend. This threw me for a loop. Shouldn’t a company want its employees to work all hours of the day?  The thing is that thoughtbot understands that the best code is written during bank hours. This doesn’t mean that thoughtbot employees don’t code at home. Everyone is encouraged to work on open source and side projects at home; however, all client work is done during bank hours when we are writing our best code.

A better way to build software

One of thoughtbot’s informal mottos is there is a better way to build software. After 5 weeks here I can tell you that the fine folks here have got something right. They write great code in a great atmosphere with no stress.