Rypple and the Joel Test

I’ve been an avid reader of Joel Spolsky for the past 3 years. Joel has the rare ability to mix insights in software design and development with humor and practicality. It’s little wonder that he’s become an authority on the subject. One of his best known articles is the Joel Test. Ever since I read that article, I’ve been using it as a benchmark for IT companies.

What is the Joel Test? It’s a quick way of measuring the quality of a software team.  A score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. According to Joel, “most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.”

Well, Rypple is a young company and certainly no Microsoft (yet).  And we’re an agile team so not all of these rules apply. Here’s how we stack up with a little bit of agile adaptation:

1. Do you use source control? yes!

Gone are the days where developers fly by the seat of their pants and not use source control, so this one is a bit of a freebie.  But we’ve given a lot of thought in the layout of the repository. For one thing, the repository is broken down by modules, and tests and code are separated. Oh joy!

2. Can you make a build in one step? yes!

We can one-button-deploy right into Rypple. When one of our developers performs the difficult task of pressing the “GO” button, source code is retrieved and compiled, tests are run, results of the compilation uploaded to our servers and the latest version of Rypple is available to all Rypplers, automagically. That’s a good thing because we release a new version of Rypple every week (sometimes multiples times a week). This frees up developer time to focus on what’s important: developing a delightful experience for you!

3. Do you make daily builds? yes!

Like many agile teams, we’ve taken this a step further. Since we release a new version of Rypple every week, we can’t wait until the last minute to make sure it works. So we have hourly builds providing us with a constant and up-to-date version of Rypple to test on.

4. Do you have a bug database? yes!

Bugs untracked are bugs untouched so yes, we track our bugs. Very few developers can track all the bugs in their head, and while James Tam may have a photographic memory, he’d still rather focus his gray matter on solving the next technical or usability challenge (or weight challenge!)

5. Do you fix bugs before writing new code? yes!

Have you ever started reading a book, left it for a couple of weeks and then tried to pick it up again? It takes a while to get back into the story doesn’t it? Now what if you had to expand on the story using the same universe, making sure that all characters and settings are consistent? This context-switching is similar for development, so we try to fix bugs (Gasp! Yes there may be bugs…) while the code is fresh in our minds.

6. Do you have an up-to-date schedule? yes!

As much as I hate making schedules, I’d have to admit that without a schedule, how can we know when and where all the pieces of the Rypple puzzle come together? The rest of the team agrees. Hence, estimates are made and tracked, and we have a regularly updated 3-month schedule posted on the wall near David Priemer, our Product Guru.

7. Do you have a spec? yes!

We’re agile. Who needs specs? Well, in agile methodology, specs are user stories and every team member contributes, since everyone is fully immersed in the design of Rypple. We’re experimenting with different levels of detail in our user stories for different needs and audiences.

8. Do programmers have quiet working conditions? yes!

For better communication, our developers sit together in the same room. Since we’re a startup, working conditions were chaotic in the beginning, but we realized the productivity loss when developers have to constantly context-switch, so we’ve introduced some processes. Daniel Debow, our co-CEO, had a little sticky which he incremented every time he interrupted us.   Discussions in the room are now limited to technical discussions. When all else fails, we can hide behind our 22″ monitors and put on some Britney Spears (Tiho).

9. Do you use the best tools money can buy? yes!

Our CEOs, Daniel Debow and David Stein understood the value of tools from day 1. They understood the 9-50% productivity gain from adding a second monitor. Books and self learning are also heavily emphasized. Our library is growing ever so rapidly and our homework grows by the day. Now if only I can find an article outlining the productivity gain from Rock Band, we’d be set!

10. Do you have testers? yes!

We see testing as an integrated activity, not an isolated one. The entire Rypple team are testers, right up to our CEOs. The next version of Rypple is always up-to-date and available internally and everyone is aware of who’s working on what, so we all try to break the functionality when it’s ready. And yes, sometimes it does break.

11. Do new candidates write code during their interview? no

Hrrmm. This is a good one that we’ll consider for future interviews.

12. Do you do hallway usability testing? yes!

Just like testing, usability testing is a total team effort to us. Each and everyone of us is consistently using the system and testing new features without being exposed to it. On top of this, James Wu, our User Experience Expert Extraordinaire (UEEE) is constantly conducting experiments and reaching out to our users. Oh, and did I mention that he sits right beside me?

So, so far so good.  We’re doing well on the Joel Test and we hope that translates into a delightful, simple and useful Rypple experience for you.  How do you think we are doing?