Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)


Posted by Wed, 04 Jun 2008 16:13:00 GMT

Kudos to the 37signals team for launching what looks like a nice way to get the word out about their products.

I’ve been using Basecamp for three years and it’s been a great tool for collaborating with our clients.


Disclaimer: This is my get-rich-quick scheme for the day.

The Art of Delivery, part 2

Posted by Thu, 22 May 2008 17:42:00 GMT

Two years ago, I wrote an article titled, The Art of Delivery. I wanted to post a few updates based on how our process has evolved since then (and continues to).

Over the past few years, we’ve been fortunate enough to work on quite a diverse collection of projects. This has enabled us to work with many different clients and solicit feedback on our process. This has given us an opportunity to evolve a set of best practices that fulfills the long-term project goals/budgets of our client while making sure that we’re able to maintain a design and development process that is agile.

As I’ve mentioned in previous posts, our team typically bills work per-iteration on projects rather than per-hour or a flat-bid per-project. Since iterations are bite-sized pieces of the entire project and limited to 1-2 weeks, our teams estimates are much more accurate and we’re able to keep things rolling and on track.

stay on track

The basic structure of our project looks like this.

  • A Project has many releases
  • A Release has many iterations
  • An Iteration has many deliverables
  • A Deliverable has many tasks

Before we begin working on an iteration, we outline a set of goals that we want to create solutions for. This process comes out of discussions between our client and us until we agree on what is the highest value/most critical to the success of the project, based on our shared understanding of where we are today. These goals translate into Deliverables, which in a typical iteration might require Interaction Design, Interface Design, or Development. We tend to break our process up into stages so that Interaction Design on Module XYZ would be implemented in a following iteration. This is because it’s unrealistic to expect someone to provide an accurate estimate on how long it’ll take to implement something before you know how people will interact with it.

Within any given iteration, our team is spread across several sets of deliverables. As a team, we breakdown these deliverables into smaller sets of tasks. It’s our aim to keep tasks smaller than a full days worth of work as it’s much easier to measure progress across the iteration when we can track tasks at a granular level.

Essentially, tasks are the individual steps needed to achieve these goals. We don’t go out of our way to list each one of those during an estimate process as some tasks take less time than it takes to generate an estimate for them. Each person providing estimates should avoid getting too granular and aim to find a good balance that compliments their workflow.

Like most things… mileage may vary.

Through this process, we can get calculate the estimated costs for each deliverable, which then provides us an cost for the entire iteration. In addition to deliverables, we also budget a set of hours/days so that we can be compensated for handling small requests, bug fixes, and project management. It’s important to factor these things into your process.

In future posts, I’ll discuss how we’re handling this process while working on multiple projects… as that’s where it can chaos can start if you’re not careful. ;-)


How does your team work? As we’re always evolving our process in an effort so that we can be more efficient and speed up our delivery cycle, I’d love to learn from those in the community.

Portland is calling... (you)

Posted by Fri, 11 Apr 2008 05:30:00 GMT

We’re not looking for rock stars or ninjas at Planet Argon. ;-)

We’re looking for individuals that share our core values.

  • COLLABORATION – We believe that an open dialogue between all members of a group helps to produce more reasoned and intelligent decisions.
  • ENTHUSIASM – We recognize the unique power of people who are passionate about their craft. We believe that fun is an essential ingredient in a collaborative and vibrant company culture. We think happy people make better software.
  • COMMUNITY – We are part of many communities. Our neighborhoods, our cities, our workplace, and our professional communities. We give back to our communities by implementing socially responsible business practices and sharing our knowledge and tools with our peers.
  • VERSATILITY – We believe that it is important for our team to be open and flexible, as well as the work that we do. This allows us to adapt to change and encourage innovation.
  • EXECUTION – We value action and when people make things happen. It is important that we follow through on our commitments, plans, and ideas.

..maybe you’re a .NET/Java/PHP/Python developer (who secretly plays with Ruby on Rails at night/weekends). We’re looking for an intermediate-level Rails developer to join our team. Ideal candidates would be in the Portland, Oregon area or willing to relocate.


If you’re interested, take a moment and introduce yourself.

Managing Required Gems on Rails Projects

Posted by Thu, 27 Mar 2008 02:27:00 GMT

We’re starting a new project and I’m finding myself adding things to the code base that we’ve done in the past… hence the last few posts. As we’re doing this, I’d like to highlight some of the little things that we do on each project to maintain some consistency and in that process reach out to the community for alternative approaches.

I’m intrigued by the vendor everything concept, but we haven’t yet adopted this on any of our projects (yet).

What we have been doing is to maintain a REQUIRED_GEMS file in the root directory of our Rails application.

For example:



Everybody on the team (designers/developers) knows to look here to make sure they have everything installed when beginning to work on the application.

This has worked fairly well from project to project but since we’re starting a new project, I’m curious if anybody has some better ways to approach this. Should we look more seriously at the vendor everything approach or are there any alternative approaches?

Campfire messages in Growl

Posted by Wed, 05 Mar 2008 21:24:00 GMT

Our team has slowly been transitioning from IRC to Campfire (iPhone interface helped with this decision) for internal team discussions. Earlier today, I decided to setup Campfire to connect to Growl. There are a few scripts to do this, but I figured that I’d consolidate the steps here for my teammates and share with everyone else in the process.

Step 1: Get stuff installed

You’ll need to install the following programs on OSX.

  • Growl (install and run it)
  • (run a web site in it’s own desktop app)
    • Follow instructions on their homepage (requires restart of Safari)

Step 2: Setup Campfire

Once you have everything installed, you can go ahead and create your Campfire Fluid application. You’ll need to provide your Campfire URL and a name for the application.

Campfire Fluid
Uploaded with plasq’s Skitch!

Once you get it running, you should be able to run your Campfire application in it’s own window.

Campfire: Blogging
Uploaded with plasq’s Skitch!

Step 3: Install the Campfire Growl script for GreaseKit

Next, you’ll want to install this script, created by Tim Harper, on within your Campfire instance.

Under the Userscripts menu, you’ll see: Browse

Uploaded with plasq’s Skitch!

Find your way to the script (search for: “Campfire Growl”) to find and install the script.

Growl Notifications with messages for campfire and fluid 2013
Uploaded with plasq’s Skitch!

Once it installs, you’ll then need to activate it in the Fluid applications management interface. Within Campfire application, go to Userscripts > Manage Userscripts.

manage userscripts
Uploaded with plasq’s Skitch!

Then activate it like so:

activate growl
Uploaded with plasq’s Skitch!

..and that’s it! When you’re not focused on Campfire… you should see Growl notifications when other people are talking in the active room.

Moved to our new studio

Posted by Wed, 21 Nov 2007 13:56:00 GMT

One of the reasons why I’ve been too busy to write on my blog lately is that we recently moved into to a new studio. We had a lot of preparation to do before we moved in and are finally getting settled in the new space.

We took the space from…

Planet Argon - Studio BEFORE improvements

To this…

As you can see.. we have lots of natural light for the entire team…

I think that Chris Griffin shares the same excitement that I do about the new space. ;-)

Chris Griffin jumps for joy!

We’ll be posting more photos on the Planet Argon flickr stream over the coming weeks as we get the studio organized. :-)

Older posts: 1 2 3