Rails on the Run

Rails experiments by Matt Aimonetti

Browsing Posts tagged client

Wow, it’s been a while since I blogged. With all the cool kids saying that spending time reading RSS feeds is overrated (see Defunkt’s keynote for instance) I even wonder if people will ever read this post!

Anyways, I have been quite busy preparing courses for classes I gave to a bunch a great Engineers at one of the Fortune 100 companies based in San Diego. I was also planning my big vacation trip to Europe and wrapping up few projects.

However, during my exile overseas, I came to the conclusion that Rubyists don’t scale. Since Twitter became stable again, we don’t hear many people ranting about Rails not scaling anymore. With one of my clients’ app handling around 7 million requests/day I can tell you Ruby/Merb do scale quite well! But ruby developers don’t seem to scale for some reason.

Maybe saying that we(Rubyists) don’t scale isn’t technically correct but that’s basically what one of my client told me.

Let’s go back in time a little bit and follow my client who we will call clientX.

  • ClientX has a great concept and wants to conquer the internet.
  • ClientX hears that Rails is the way to go.
  • ClientX hires a contractor/mercenary/freelancer/guns for hire/consultant (aka Me)
  • Me builds a killer app using Merb (killing framework)

  • ClientX raises loads of $$$

  • ClientX wants to hire a team because Me doesn’t want to become a FTE

  • ClientX and Me look for Rubyists wanting to relocate and get a decent salary
  • ClientX *can’t find someone they consider good enough and who would accept their package

  • Many JAVA guys are available on location and accept lower packages

  • Ruby app gets ported over to JAVA
  • Me sad :(

So is it really the Rubyists’ fault if we don’t want to relocate and only accept higher packages? Should I blame Obie for telling people to charge more and teaching how to hustle? Or should we just tell clients that it’s time to get used to working remotely?

Honestly, I don’t think any of the above explanations are valid. Ruby is the new/hot technology and very few people have the skills and experience to lead major projects. These people make a good living and enjoy their “freedom” and dream of building their own products. Most of them/us value their work environment, family and are reluctant to move.


At the same time, companies do need people locally(at least a core team) and can’t always afford the cool kids.

ClientX, quite frustrated by the whole hiring process told me once: “you Ruby folks are too unavailable and difficult to work with! We need a committed team that actually cares about the company/product.”

That hurts when you worked hard on a project and just can’t satisfy the client by finding guys willing to relocate and work for them. It gets even more painful when your code gets entirely ported over to JAVA!

But at the same time I understand ClientX’s motivation, PHP guys are cheaper, JAVA guys are more available, why in the word did we go with Ruby and are now struggling finding people?

Once again, there is positive and negative side in everything, by choosing Ruby and a “great contractor” ClientX was able to catch up with the competition and even pass them in no time. They quickly raised good money and got everything they needed to become #1. I don’t believe it would have been possible to do the same thing so quickly with JAVA for instance. However choosing a cutting edge technology means you need to look harder for talented people.

It’s too bad the code gets rewritten in a different language but at the same time, I do my best to facilitate the process and to keep a good relation with my client. There was nothing personal in the decision, it’s just too bad we were not able to keep on using the latest/coolest/awesomess technology available :)

To finish on a positive note, here is the solution to scale your Ruby task force provided to you by the #caboose wisdom:

Based on my conversations with other #caboosers who hire other devs, the word in the street is that you just need to get one or two great ruby guys (who will probably cost you a lot) and find a bunch of smart people to train. You’ll end up with an awesome team of scalable rubyists ;)

I’ve been a freelancer/consultant/contractor/mercenary for many years now. However, until now, I used to do that on the side. Few months ago, after thinking a lot about it, I finally decided that freelancing was what I wanted to do. I left my job and started my own adventure.

The first reason for this switch was a desire to be more involved with my clients’ projects and accept bigger projects. Then there was the obvious flexibility brought by this new position (I can now work wherever I want, usually on my deck). Finally I have to admit that financially things are better now.

This post won’t be about helping you deciding if you should freelance or not. I’m just curious to know how you work, how do you deal with your clients, deadlines, payments etc…
So instead of simply asking, I’ll explain how I do it and I hope that you will share your ways of doing it.

How do I do it?

Choose a client

Clients are the heart of your business. At first, you might be worried not to find enough work and you will take any project. WRONG! this is the worst thing you could do. You would not take any job just because they are willing to give you a salary, would you?


I. find a match

Personally, I believe in Agile methodologies, regular code release, iteration planning, daily stand-ups, test driven development, continuous integration… This is what I call my ‘work values’.
If I see that a potential client’s ‘work values’ are opposite to mine. For instance, he might like the waterfall approach, writing a lot of documentation before we start coding, doesn’t see the essential need for a good test suite, then I know we would not be a good match.

It doesn’t mean that I’m right and she/he’s wrong. It simply means we don’t work the same way and that a work experience together might be frustrating for both of us.

A lot of clients don’t know how to approach software development and they might not have strong ‘values’ yet. In this case, I explain how I work and I try to read their reaction. Sometimes, you can agree on a ‘trial period’. Being freelance, you are more than likely free to quite whenever you want. However, you’ll find out that is not a good experience for neither of you.

II. Check on the project


My first rule when it comes to choosing a project: if it doesn’t interest me, I don’t take it.

It’s very simple: to do a good job, I need to be passionate. If the project is boring or simply doesn’t attract me, I know I won’t be able to serve my client the best I could.

Second rule: Code review

Often, you might be contacted by people who already started a project but for some reason need you to take the project over. That happens often when a client tries to save money by taking the cheapest guys around (often overseas) and realize it doesn’t work for them. Or maybe, your client’s main developer had to leave and they need your help. Finally you have the case of a project growing and they simply need more people to work on it.

I always ask for a code review before I accept a job. Why? Simply because a CEO can tell how much he believes in Agile software development, that he has a portrait of David Heinemeier Hansson above his bed and that he knows getting real by heart, a quick look at the code will reveal the truth. It will also tell you a lot about the other guys who worked on the project.

  • testing suite: do they have any? Rspec? Unit test? Selenium? What’s the test coverage? Do the tests pass?
  • test readability: Did the developers try to be clever and the code is very obscure?
  • best practices: Did the team follow most of the best practices? Why not?
  • reinventing the wheel: Did they make a proper usage of plugins/gems.
  • living on the Edge: Are they running on Rails Edge? Would it help?

I usually don’t worry much about how they deploy, since that can be changed easily.

Looking at your code review I try to evaluate few things:

  • what’s the team’s tech level?
  • what kind of pressure the administrative people put on the tech team?
  • what do the teach value?
  • do I need to rewrite a lot of code?
  • do I seriously need to improve the test coverage?
  • is it a real mess and I’d better give up before starting?

A few months ago, Jade Meskill recommended I read “the dip” from Seth Godin. If you haven’t read it yet, get a copy. It’s a very simple and obvious book but it explains very well why and when you should give up and when you keep on struggling. And that’s exactly what we are trying to do. We want to evaluate the effort needed to succeed (if it’s doable).

III. Build a relationship


Business is all about relationship. Both your client and you have needs. By creating a relationship you will try to fulfill most of your needs. Let’s look at an evaluation of my professional needs:

  • I need to be challenged
  • I need communication
  • I need guidance
  • I need deadlines
  • I need results
  • I need to be valued

And here is what I cam up with when I tried to estimate my client needs:

  • he needs business value
  • he needs to feel special
  • he needs to be reassured
  • he needs to keep control over the finance
  • he needs to make sure he doesn’t waste money/time with me
  • he needs to plan the future

There we go, we have the base of our relationship. As long as most of our needs are fulfilled, the relationship should be strong.

As you can see by looking at the list above, the client needs to be convinced that I am the perfect fit they were looking for. On my side, I want them to realize that we are lucky to work together and I want them to value me.

Money makes the world go round, especially in a business relationship and especially in the Western world.
Your rates are a simple way to say, this is what I’m worth. If you are willing to pay my rates, you are valuing me. Obviously rates can be negotiated but be careful, somehow they will always represent your value.

So how do I build this relationship?

  • be frank, open and transparent.

I don’t want my clients to feel that I’m hiding things from them. For instance, I’m always running two projects at the same time and I make that really clear at the beginning before I start working on a contract. My client A knows that I will work 17-20 hours a week on his project and 17-20 hours on a different project. If I have to miss one of our stand-up, I usually explain why.

Trust is very important when you are an outsider and even more when you work remotely.

  • Provide visible business value on a weekly basis.

At least once a week, I have a quick demo with my clients and if possible their co-workers. This demo is really important for a client since he can then visualize the business value added to his product. He will feel in control, reassured and will be able to evaluate the situation and plan the future of the product. Usually clients who worked with other developers/methodologies also feel special since they would usually only see business value at the end of the project. By the way, the demo is usually done on the production application so we are talking about real business value.

  • Make the client the center of the decision making process

In my usual process, we have a special meeting every monday. During this meeting, we plan the work for the coming week/iteration. I simply help the client breaking down his tasks in small chunks that we could handle in a week. During this meeting we also agree on this iteration priorities. In general we already created a queue/backlogs of tasks that need to be executed. I simply let the client make his choice to what is really important. In general a client wants everything done right away exactly how he has it mind. Well… the reality is really different. A client doesn’t have to understand the concept of polymorphic association to make decisions. Actually, he doesn’t care how you do it as long as it’s well done. However, your client should know how to prioritize things, he probably already does that all day long.
Converting the technical details into simple concepts that make sense to both you and the client will seriously help the project. I don’t have to worry about delays, I don’t make these decisions, my client does that for me and he likes having control over budget/time line.

To sum-up, I believe that by choosing a client that matches my view of software development, a project that sounds interesting to me and building a strong relationship, we will have a good end result and a win-win situation.

What about you? How do you manage your projects, clients? Do you agree with me, or do you think I’m idealist and in the real world things don’t happen like that?