---
title: 'Retrospective: Fashionopoly'
teaser:
tags: news
author: Dan Croak
published_on: 2010-05-07
---

A couple of weeks ago, [we
announced](https://thoughtbot.com/blog/post/543865612/big-bang) our plans to
start an app on Monday and launch it on Friday. We'd like to share lessons we
learned.

## The Result

The production application went live at
[http://fashionopoly.com](http://fashionopoly.com) on Friday. It's currently
invite-only so there's not much to see publicly. I recorded a screencast (it's
not a "talkie") but I can't show that, either. Ah, the suspense. Sorry!

Please accept these fashionable photos of Los Angeles Laker superstar Kobe
Bryant instead:

![Kobe, I mean what is this?][kobe]

[kobe]: http://media.tumblr.com/tumblr_l2202zUIdZ1qz5x9p.png

You'll recognize the features we completed, however: sign in with email &
password, sign in with Facebook, beta invites, scoring system, commenting, post
to your Facebook wall, like, flag, moderate, edit your profile, upload an image
from your hard drive, upload an image from a <abbr title="Uniform Resource
Locator">URL</abbr>, GET shopping results from the Amazon API, tagging, search
by tag, filter by category, filter by location.

## Tools

The obligatory set of tools we used includes:

* [Heroku](http://heroku.com/) and S3 for deployment
* Clearance and Clearance Facebook for Facebook integration. Clearance Facebook
  is a private library we wrote for another project. It uses Facebooker under
  the hood. Like Clearance, it has a set of Cucumber features that mock out
  Facebook. If this project came a few weeks later, we would have used **the new
  Facebook API** but we felt it was safer to go with what we know.
* Cucumber, Webrat, RSpec, Shoulda matchers,
  [Timecop](https://github.com/travisjeffery/timecop), Webmock, Factory Bot,
  and Email Spec for testing
* Geokit and [jQuery
  Auto-geocoder](http://github.com/tristandunn/jquery-auto-geocoder) for
  location stuff.
* Searchlogic and jQuery for searching and filtering. I would like to write a
  separate article about this.
* [Less CSS](http://lesscss.org/) and Formtastic for DRYer, faster <abbr
  title="Cascading Style Sheets">CSS</abbr> and forms.
* Basecamp, Campfire, and a real-life whiteboard for communication. The client
  and half the thoughtbot team also shared our conference room.
* [Pivotal Tracker](https://www.pivotaltracker.com/) for user stories.

## Speed Lesson: Derivation

Look at that list of features. We've written each of those at least once
before. Nothing was really from "scratch." We could either use a gem or consult
old code if we got stuck. It's the first reason why we were able to finish so
many in one week **without compromising our values** (everything was written
test-first, outside-in with acceptance tests as the outer loop and unit tests
as in the inner loop).

The result still feels unique to me, though. People smirk when you say you're
building a "social" anything but the paradigm works.

The derivation also makes the one week concept more reasonable. We're working
on other, longer projects where it wouldn't make sense. It's time consuming to
learn **the language of the construction or medical industries** versus the
language of a social site.

## Speed Lesson: On-site customer

This is an [XP rule](http://www.extremeprogramming.org/rules/customer.html).
It's something we've done with our other clients, but not consistently. I would
highly recommend this for any consulting engagement for the simple reason:

**The many small decisions that must get made... get made faster when the
customer is on-site.**

The cumulative gain is very noticeable. If your client balks at the idea, I
like the quote from that XP rules page as a response:

> This may seem like a lot of the customer's time at first but we should
> remember that the customer's time is spared initially by not requiring a
> detailed requirements specification and saved later by not delivering an
> uncooperative system.

## Speed Lesson: Heroku

It goes without saying that Rails is a productivity enhancer.

The combination of user stories, TDD, continuous integration, spikes, and
on-site customer was another clear productivity enhancer for us. Let's call
that a subset of "agile" or XP.

The third productivity enhancer was Heroku. Sendgrid, Delayed Job, Hoptoad,
deploying to staging and production, thumbnailing images and storing on S3. All
of that stuff is **second nature** on the platform. They're solved problems
that take minutes, not hours of configuration or tweaking.

I came across a presentation by Ian McFarland of Pivotal Labs this week called
[Agile, Rails, and the
Cloud](http://assets.pivotallabs.com/426/original/agile__rails_and_the_cloud_bizconf_2009.pdf)
that makes the same argument and I couldn't agree more.

## Strategy Lesson: A Brand Guideline

When I showed my colleagues a draft of this post, they said, "I'd expect to
hear stories about making tough decisions on prioritization." This actually
wasn't an issue. There were user stories ready in Pivotal Tracker. We made a
point to prioritize them first thing Monday morning. About halfway through the
week, we wrote the major features on the board that we wanted to get done and
just did it.

On the other side of the coin, **the sloppiest part of the project** was
decision-making around design. There were six cooks in the kitchen: two
designers on our side and four people on the client side.

We should have clarifyied the brand vision and target audience before we
started. We didn't draw the line, asking for adjectives describing the desired
brand ("innovative", "stylish", "reliable", etc.). We didn't ask that the
client accept or reject the designs on the basis of the brand vision or target
audience instead of making requests for color, layout, or other design
elements.

I think we all agree that [design by committee results in a design that is the
lowest common denominator](http://dustincurtis.com/dear_dustin_curtis.html). It
also results in a lack of cohesiveness in the design. **Worst of all, it's
slow.**

We fought those forces as much as we could but there's definitely room for
improvement.

## Strategy Lesson: A good product today

Paraphrasing Rousseau, who was part of the client team:

> A good product today is better than a great product a month from now.

I love their strategy:

* Use an experienced team like thoughtbot
* **Build a minimum viable product in a week**
* Privately validate that customers want it
* After customer validation, open to the public to validate the business model

This is basically the [Customer
Development](http://en.wikipedia.org/wiki/Steven_Gary_Blank#Customer_Development)
risk reduction methodology with the twist of white-hot energy focused for a
week on product development preceding a longer period of private customer
development.

The book "Four Steps to the Epiphany" is the Customer Development
bible, but it's ironically a slow read. Very dense. I'd recommend Ash Maruya's
"Customer Development Checklist for My Web Startup", [Part
1](http://www.ashmaurya.com/2010/02/customer-development-checklist-for-my-web-startup-part-1/)
and [Part
2](http://www.ashmaurya.com/2010/02/customer-development-checklist-for-my-web-startup-part-2/).

Other people frequently make the mistake of trying to get their startup going
"cheaply" by hiring night-and-weekenders. The product development process
inevitably drags on, and sometimes never launches. Either the founders lose
motivation or have to spend more money to do it right. In the end, **it's not
cheaper** to make your customers wait for a web startup-style product.

As Rails developers, we all know about the power of constraints. The focusing
power of the one week constraint is as real as other constraints. It's also a
ton of fun!