Selling Rails

April 21, 2006

No doubt about it, I am up to my eyeballs in Ruby on Rails projects. It’s exciting to see what people want us to build—everything from niche content management tools, to workflow management apps, to massive social networking projects. Proposals come in from companies ranging from basement startups to tier one financial institutions. Rails is certainly not a secret anymore; it’s a genuine phenomenon, and it’s attracting a lot of attention.

That said, there’s a big difference between attracting clients and signing contracts. Somewhere along the line, a decision is made to start writing checks, and if you’re in the business of writing software, it’s extremely important to understand why that decision is made.

So, here’s the stunner for a lot of us geeks: that decision has little to do with Rails.

“OMG,” you gasp. “WTF. Heretic!”

I know, I know. I’ll go back to drinking the Kool-Aid in a bit … But hear me out!

Rails won’t make your product a better product. Rails won’t give you the features that your customers want. Rails won’t manage your project and make everything run smoother. Rails won’t cook you breakfast, mend your pants, walk your dog, or print bumper stickers1.

The trick to selling web applications is Delicatessen’s secret ingredient: it’s all about the people2.

People write code. People design and manage infrastructure. People answer the phone and fix problems. People create attractive designs and optimize interactions. And, thankfully, people also cook breakfast, mend pants, and walk dogs.

Those who are willing to invest a significant amount of money in a web application want confidence in the people who build it for them. They know technologies don’t guarantee anything, and they know buzzwords don’t make the product. They want developers who produce efficient and high quality code, designers with good taste and excellent CSS skills, and managers who return their calls and take a personal interest in their projects.

Quality people can produce excellent products with whatever platforms or languages they’ve honed their skills on. Java? Sure. PHP? Why not? C#? Yup!

So, why do we exclusively develop with Ruby on Rails? Because we’ve used Java, PHP, C#, Python, Perl, and a shocking array of slightly obscure languages. We’ve seen how language affects architecture, run the gauntlet of application servers, and rescued projects from spaghetti code hell. We’ve started our own companies, created our own products, and in the end, we recognize that Ruby on Rails works well for us, and how we build web applications.

In short, the magic happens when the right people people get their hands on the right tools for the job.

Sell the whole package: your people, your resources, your experience .. not just the technology.

1 Actually, this is a lie—Rails does print bumper stickers. One of our clients uses Rails to manage the printing of custom calendars, photo mugs, and all sorts of other photo paraphernalia.

2 Taking the Delicatessen analogy a bit further: Technology may be the buttery creamy icing, but people are the delicious fudgy cake; technology might catch a client’s attention, but nothing satisfies the appetite like good people.


When pair programmers go home for the night, they leave behind software and documentation—these are persistent artifacts. Persistent, meaning it lasts longer than the process that created it; an artifact being something with inherent value or purpose.

Persistent artifacts can be found everywhere in business. Products, for example. Shoes. Watches. Chopsticks. I’m not going to claim that pair processes work best for building all products … but they do work pretty darned well for written products.

What kinds of written products do you produce in your day to day life? Notes jotted down and kept in your pocket, casual e-mails sent to friends and coworkers, presentation outlines, meeting minutes, proposals, memos … even software.

We do a lot of writing. Of course, not all of it is well suited for pairing—things like your thank you note to Aunt Mildred, or personal notes from the morning standup meeting.

On the other hand, things like marketing copy, sales proposals, and software—these are substantive things that represent your team (business, division, etc.). They require attention to quality, and their content frequently crosses boundaries.

Sound familiar?

Lets take the example of a project bid—something I actually have to deliver this afternoon.

Now, theoretically I could just write something up, e-mail it to Jeremy for technical approval, wait for his feedback, incorporate his estimates and adjustments, then send it out.

But, dangit, theory just doesn’t match up with reality. Jeremy will see some flaws or opportunities and ask a few questions. I’ll respond in kind, but he’ll be heads-down on a project. He’ll eventually come back with his response, but I’ll be knee deep in other correspondance. The cycle repeats. You get the idea. We’ll get the job done, but these are the kinds of patterns that contribute to continuous partial attention and missed opportunities.

What’s the pairing approach?

Jeremy and I reserve time in the conference room1. I bring my laptop, he shows up empty handed. We spend a couple of minutes reviewing the client notes on Basecamp and then we hash out an outline for the bid. I type; he looks over my shoulder and helps navigate. Technical and client questions can be instantly answered (or at least identified as open), mistakes are caught (technical or otherwise), and in the end we have a bid that we’re confident in and are willing to take responsibility for.

Good times.

So, where do you think paired writing could be valuable in your business?

Where do you think it’s superfluous?

Let me know!

1 We have an “open pit” development environment. I should write something about that later.

Yesterday I posed a question: can pair programming techniques be used to improve other business processes?

One of the aspects of pair programming is information transfer—that two people who work directly with each other have a much stronger mutual understanding of the task at hand.

Where this seems to be most important is when crossing boundaries of responsibility. For example, I’m responsible for delivering a price and spec for an iteration, and Jason is responsible for delivering the code. In order for us to be responsible for what we’re doing and have confidence in our goals, we need to a thorough understanding of what and how we’re going to do it.

Where else in business can these boundaries be found? Off the top of my head:

  • Deployment and development: what are the deployment requirements for an application in development, and what are the deployment capabilities?
  • Development and sales: what does the customer want, and how much will it cost to build?
  • Sales and marketing: what do our potential customers respond to, and what through what channels can we reach them?

These are all things that fit the “pair” model well—they all generate persistent artifacts (documentation, code, marketing literature, etc.) and require detailed mutual understanding of the issue.

Where have you found these boundaries in your business?


April 18, 2006

… in the development room:

TDD makes writing code super easy. All the hard thinking happens when you’re writing the tests and designing the API, and then it’s just red light / green light when you’re writing the implementation.

It seems that writing your tests first helps enforce the idea that you need to understand a problem before you can solve it. Particularly with large projects, building a comprehensive test harness is a fairly cheap way to explore architectural issues without committing to a particular implementation.

I had an interesting idea while talking with Jeremy and David about pair programming: Could the same technique be applied to business processes?

Pair programming can be a really marvelous technique, especially in sections of critical code. It cuts out the communication lag between writing and review, keeps developers in sync, and helps the people involved stay focused on both the immediate technical issues and the overall architecture. I have ring-side seats when Jeremy and Jason take on a tricky component … and it’s an amazing thing to watch.

Anyhow, back to the original idea: can this practice be applied to business processes?

To frame the question a little better, lets look at what pairing achieves in the development world: high quality persistent artifacts, and detailed mutual understanding. That is, good code that sticks around for a while, and two people who know it inside and out. From a development perspective, you can’t get much better then that.

Can this be applied to sales? Marketing? Management? Food for thought.

I’ll write more later.


April 14, 2006

Today’s my birthday, and my fine friends and cow-orkers at PLANET ARGON wrangled some excellent presents:

  • A bulk pack of blank, white, 3×5 index cards. Brilliant. Possibly the most useful and versitile tool ever invented. Not only can they be used to Get Things Done and organize day to day tasks, but they can also be folded into paper footballs and/or throwing stars to entertain and/or defend the office.
  • A compact Fisher Space Pen. Not only is it sleek and shiny, but it also (apparently) can be used in the boiling, freezing, upside-down, and otherwise exciting environment of outer space. If the Martians ever get hot for Rails, I’ll be ready for the sales call.
  • A gift card to the local bakery and coffee roaster that jump starts my mornings.

Good times!