In response to my article, Audit Your Rails Development Team, Tim Case writes,

“I think what you are doing has value and I’ve been anticipating that someone in the rails community would step up and do this, hence the question I posed because I’ve thought about that thorny issue too. I have a feeling Planet Argon is making the first step in a direction that has been building, Peer review has the potential to be positive for the entire community, provided that it’s shepherded properly and with care.”

It’s been just over a year since we first made a public announcement of our Rails Code Audit and Review service and we’ve had different types of clients inquire about it. We make sure to call it a code audit and review because we’re not aiming to only point out flaws. We see our service as a way to help stake holders gauge the capabilities of their developers while also providing developers with some more insight to how things could be done differently. There are a lot of developers using Ruby on Rails now and it’s safe to say that there are many that aren’t very good yet. Some may argue that the ease of getting started with Rails makes it easy for inexperienced developers to stay just good enough and never take the next step. We’ve seen some beautiful code and we’ve seen some horrific code. Some of our clients have made the tough decision to fire their existing freelancers after we’ve completed our analysis… but we’ve seen several situations where our clients were happier with their developers after.

For example, we recently completed a code audit and review for a client, which came to us with some concerns about their development team. Things seemed to be going slower than they thought it would and really wanted to have an outside opinion about the quality of their work. Overall, their application was being developed really well and the biggest problems that they had were related to a lack of testing. So, we’re now walking them through the process of integrating RSpec into their development process. Their development team admitted that they suffered from a lack of testing, but were very honest about the fact that they just didn’t know where to begin as it wasn’t something they had time to learn before. We’ve been able to provide them with some direction and now we’re available to answer questions and review their work from time to time. The outcome was good for everyone. The developers are better off because their manager has more confidence in them. The manager has more confidence in the product as a whole and knows exactly where his team should focus their attention on next. We’ve gained a new Rails consulting client and get to help them with their cool project.

While we love working on entire projects from start to finish, we also love working with other developers and development teams. This has been one of our favorite types of client relationships. We’re currently working with a handful of people as they work their way through the project life cycle and we’re always a phone call, Basecamp message, or email away from assisting them. I feel that these types of services are important to the Rails community, because we’ve witnessed situations where clients were unhappy with Rails because they weren’t happy with their developers. We’ve seen people drop Rails in favor of something else because of the poor quality of code that was being written in Rails. When bad perceptions spread, it’s bad for the community as a whole.

What we can do, is become the backup team for the client and/or development team. Should they run into any weird deployment issues at 2am on a Sunday morning or aren’t able to track down the cause of some performance issue, we’re another set of people that can help out. While we don’t know every nook and cranny of our consulting clients’ applications, we do have a good understanding of them. This allows us to dive in and help more quickly than we can for clients that call us for the first time a few hours after they had an emergency.

It’s my opinion that these types of services are very valuable and highly encourage other consultancies in the Rails community to offer them.

If you’re part of a development team and/or a freelance developer and looking for this sort of relationship, please contact us to see how we can assist you.

First of all, I’d like to welcome the more than fifty people that have joined the Rails Business group since my last post. Over the past week, there were less posts, but we did cover a few important topics, which may be of interest to you.

Subcontracting

Michael Breen asked a few questions about subcontracting for larger firms and how people set their rates when doing this. Several of the responses provided some personal experiences (good and bad) of being a subcontractor on large projects. Where some risks are and how to negotiate your rates, when applicable.

Read the discussion

Change Requests

Nick Coyne started a discussion on how to manage change requests in an Agile development process.

Dealing with large clients

There was also a discussion about how to go about responding to a 150 page RFP for a large client. A few of us offered our experiences of bidding on large projects. Read more

Join the Community

The list is about to pass 400 members and it’s already proving to be a valuable resource for all of you entrepreneurs out there. I encourage you all to introduce yourself.

• For more info: http://groups.google.com/group/rails-business

Several months ago, a few of your colleagues decided to join forces with you as you had come up with a concept for an innovative web application, shared the ideas with your friends and relatives, and began developing a business plan. After a few months of performing some initial market research, working on your pitch, and raising some initial funding, you decided to bootstrap the project and start designing and developing the product.

During your research phase, you came across several articles about this exciting new technology called, Ruby on Rails. You were impressed with many of the sites that were being developed on this new framework as well as the community that surrounded it. Your team decided that it would be a great idea to follow this trend and use Rails as the platform for your new product.

At this point, you began soliciting freelance developers and/or firms to hire for the design and implementation of your project. Eventually, you make a decision and break ground on building the product.

Let’s jump forward to the present day.

You’ve been in heavy development for quite some time. Your product has gone through a series of design changes and you’ve recently begun to allow other people to begin testing the application. You’re receiving a lot of bug reports as people use the system. Your development team quickly fixes them as they appear, but you’re noticing a trend in the development process.

The speed of implementing new features is drastically slowing down as your development team is spending most of their time fixing bugs. Along with that, they are becoming frustrated by the project because they can’t keep up with your new feature requests while trying to keep up with your growing number of bug reports. You’re becoming concerned about the stability of the product and are slightly suspicious that your developer(s) might not be as good as they suggested they were.

Did you hire a bad development team? Chances are, you may not be able to tell. You’re not a developer, so reviewing their code would almost be a waste of time. How would you know if they were doing a good or bad job? Your developers reassure you that things are going to work out in the end, but it’s going to take longer then originally planned. Along with this, your partners and investors are anxiously waiting for you to launch the product, but something feels wrong. You’re worried that launching it too soon could be the quick death of the entire project if it all comes to a screeching halt due to unforeseen bugs and problems with the application. This wasn’t how you pictured the launch of your exciting new product and you feel a lack of confidence in the entire process.

What can you do?

Before I get into that, let’s discuss some of the possible causes for this situation.

• Your development team may have grossly underestimated this project.
• You might have pushed too many features into the initial release of

the product and your development team might not have done a good job
of helping you [determine what you need, not just what you
want](http://www.robbyonrails.com/articles/2006/08/22/information-anxiety-and-solutions).
```text
-   Your development team might not emphasize testing enough in their
```text
process.
```text
-   Your development team may have begun to take a lot of short cuts in
```text
an effort to hit your launch date(s)
```text
-   Perhaps you asked for quick turnarounds on new features before an
```text
investor meeting... maybe this happened on several occasions.
```ruby
-   Your development team might not be very good with Ruby on Rails,
```text
maybe this was their first Rails project.

• …and so on.

At this point, the big question is… what’s the problem?

Can you answer this question yourself? Can your development team answer it? If not, what do you do? How can you get an accurate understanding of how stable the code base of your application is?

Answer: An independent code audit and review

Why is this a good idea? Well, when you have an independent team review your code, you get the benefit of having a fresh perspective.. and often times, an independent team can be much more critical and provide an honest assessment in a very short period of time. This is especially true if they have a lot of experience with the technology. For example, PLANET ARGON has been conducting code audits on existing projects for over two years. We’ve designed a process for checking existing code bases for mistakes that we’ve either made ourselves in the past or found in other projects that we’ve reviewed.

In fact, our process currently walks us through the following areas of your Rails application.

• Security of the application
• Privacy of users’ personal data
• Adherence to the conventions of the Ruby on Rails framework
• Scalability of the application
• Performance of the application and data model
• Testing framework and process
• User interaction (when applicable)
• Information Architecture
• Model-View-Controller (MVC) implementation and organization

Not only does this process provide you with our analysis, but we also provide you with our advice as to where your development team should focus their attention next. If your team is lacking experience in the areas that we recommend they focus on, we’re also here to help them through this with our consulting services. We’re currently assisting several Rails development teams with their testing process, refactoring, user interaction design, optimizing their site, improving their deployment strategy, and plan the implementation of new features.

In general, most freelancers and firms could/should provide you this service, but it should not be performed by your existing development team. They have a bias towards their process and this is your chance to get a second (or third) opinion on the work that you’ve been paying them for. If you’re spending several tens/hundreds of thousands of dollars into this product, an independent review of your investment should be something to seriously consider.

There are several different scenarios that could lead you to deciding to have an independent firm perform a code audit. In fact, I’d encourage you to always get an outside perspective of your team’s work.

You can learn more about our Ruby on Rails Code Audit service on our website or by giving us a call at +1 877 55 ARGON.

This past week (give or take a few days), the Rails Business group has covered a lot of topics, that might be of interest to you, should you be running a business and using Ruby on Rails. Many of the members of the new group are independent contractors and have been very open in sharing their experiences of working for themselves. I’d like to take a moment to highlight a few conversations and tips that were covered this past week.

Health Coverage

Mike Pence started a conversation about health coverage…

“Has anyone else found the medical insurance issue to be a show stopper for them? Are you one doctor visit and diagnosis away from financial ruin? I can tell you firsthand that wishful thinking won’t pay those bills…”

This started a discussion about how people are able to work on their own and maintain health coverage, which is definitely not something that should be considered lightly. Read more…

Client Expenses

Another great question was raised by Mike Breen.

“I’m going to start work on my first project that will require me to travel. How should I handle the expenses? Do I build the costs into the contract price or do I submit the expenses to the client for reimbursements? Or does this vary from client to client based on the company policy?”

The responses included links to IRS sites and sections of other peoples’ contracts. Read more.

Hosting Client Repositories

Where do you host your client’s source code repositories? Are you managing it all yourself on your own servers or using a service?

The discussion (so far) has lead us to evaluate our own solution for this at PLANET ARGON. It appears that everyone has different concerns about how they want to manage client code during the development cycle.

For example, do you allow your client access to trunk/ if they aren’t all paid up yet?

Also, it seems like there are a bunch of new commercial options coming out (and are built on Rails). Read more.

Naming Your Business

Jared Haworth writes,

“For those of you who are working as ‘independent developers,’ have you found that it makes more sense to simply do business under your own name, for example “Jared Haworth L.L.C.,” or to come up with a clever business name instead, such as “Code Fusion Studios”?”

This was a good conversation to follow and definitely raised a lot of great questions and things to consider in response to the original message. Read more.

Other Topics

• Magazines, what business magazines do you read?
• Where do you find gigs?

Join the Community!

The community is still only a few weeks old and we’re already approach 350 members! It’s been a great learning about other peoples’ experiences… as well as sharing what I’ve learned since I started PLANET ARGON (and how the name came to be).

If you hadn’t had a chance to join, stop by and introduce yourself!

So, I was trying to send AT&T wireless a support email through their online system and got stuck at the following screen.

{width=”500” height=”271”}

Come on guys… you can design a better form than this… and I’m now going to have to try and sneak in a question under a sub-topic that doesn’t apply to my question… just so I can send you an email?

Getting help shouldn’t be so hard[^1^](#fn1){#fnref1 .footnote-ref role=”doc-noteref”}.

1. ::: {#fn1}

At least I can **Print this page** and show all my
friends...[↩︎](#fnref1){.footnote-back role="doc-backlink"}
:::

In an article on FastCompany.com, Lynne d Johnson writes..

“I’ve been a paid subscriber of last.fm since 2005, and over the course of time”

I’m confused… since when did you have to pay for a subscription to last.fm?

Read the article, What will CBS do with Last.FM

I’ve been using it for much over two years and passed the 31k song mark recently. I am curious about what CBS plans to with it…

It’s been a week since I announced the new Ruby on Rails meets the business world group. Already, the group attracted over 300 members from around the globe… from Argentina, Boston, Australia, Florida, Seattle, Portland!, the Netherlands, and South Africa.

We’ve already seen some great topics come up… from:

• Project estimates
• Fixed bids versus time and materials
• Pricing
• Handling code ownership with client contracts
• Incorporating (LLC, S CORP?)
• Managing money/accounting
• Contracts

I expect that many of these topics will resurface and there has been a lot of valuable information passed around. It’s exciting to see that so many people not only want to use Ruby on Rails as a platform of choice for their business ventures, but they’re also willing to share their personal experiences and knowledge to help others move into this space.

If you’re running a business that focuses on Ruby on Rails or just considering it, you should stop by and introduce yourself.

update: membership grew from 200 to over 300 in the past day!

Several weeks ago, I announced that I will be speaking at Ostrava on Rails and had begun working on my presentation for “The Case for Rails.”

Unfortunately, there seemed to be some miscommunication within the management of the conference organizers and I will no longer be heading to Czech Republic for Ostrava on Rails.

I’d like to thank everyone who emailed me with advice on where to stay before/during/after the conference and in Prague. I really appreciated that and hope that everyone who makes it to the conference has a good time!

In an effort to increase awareness of the importance of good Interaction and Interface Design in Web Development… I suggested that today be. Hug Your Designer Day.

Designers Versus Developers

Are you seeing a lot of this in your Design and Development teams?

/>[Allison Beckwith, Experience Director and Graeme Nelson, Lead Architect]{.small}

Happy Designers and Happy Developers

Well, maybe it’s time that your developers gave your designers a hug…

/>[Alain Bloch, Web Developer and Chris Griffin, User Interface Designer]{.small}

Also… to celebrate Hug Your Designer Day, Amy Hoy was kind enough to post her slides and some audio that I recorded of her talk at RailsConf 07.

Let’s all take a moment to thank the designers who put the experience of the users first. The success of our projects rely on everyone working together. Hug Your Designer! (they might hug back…)

Amy Hoy, of slash7 fame, gave a talk titled, “ Rubber, Meet Road: Getting Designers Running with Rails”:http://conferences.oreillynet.com/cs/rails2007/view/e_sess/11632, which provided a good overview of some of the problems that designers and developers face when working together. This was one of my favorite talks, because she essentially explained several of the problems that our team has faced in the past and in many ways, still encounter from time to time. A few things that I was surprised to hear, was that several companies leave their developers to implement HTML/CSS in the Rails applications, rather than let their designers into the area. Some teams, provide a directory in public/ for their designers to write their HTML/CSS. Amy said that she preferred to work in the standard view directories (as a designer), which is exactly how our team works.

In fact, I agreed with Amy on several points.

• Developers say, “We can’t do that” too often, when really… we

mean, "We won't/don't want to) do that"
```text
-   Template languages create extra barriers to training designers.
```text
Stick with RHTML... designers won't be afraid of ERb syntax if you
sit down with them and explain some of it. Move the ugly stuff to
helpers... like you should be anyways!
```text
-   Teach your designers how to use subversion... let them break it
```text
first and then help them... they'll love you for it
```text
-   When meeting clients with a designer and a developer... don't let
```text
the developer speak too much about implementation when it hasn't
been designed yet. Interaction Design should dictate architecture
not vice-versa.

“Stop, Collaborate, and Listen” — Vanilla Ice

I’d like to personally thank Amy for being a diplomatic designer and telling the hundreds of developers that showed up for her talk to remember that designers and developers… think differently… and that’s a good thing for the application and ultimately… the user experience.

Having said that, I’d like to request that tomorrow, May 23rd, be… Hug Your Designer Day.

On Saturday, I had the great pleasure of being up in front of several hundred people with the following individuals on the the Business of Rails panel at RailsConf.

/>
[Photo by James Duncan Davidson]{.small}

Moderated by:

• Nathaniel Talbott, President, Terralien, Inc.

The Victims:

• Justin Gehtland, Founding Partner, Relevance
• Geoffrey Grosenbach, Topfunky
• Andre Lewis, Earthcode Studios
• Joe O’Brien, artisan, EdgeCase, LLC
• Robby Russell, Director, PLANET ARGON

Overall, the experience was fantastic. I really enjoyed the questions that Nathaniel and the audience threw our direction, both during and after the session. Throughout the remainder of the conference, people would catch me and present complicated business questions to me and ask for my input. I think that I even helped one guy make his final decision about which job offer he was going to accept (btw, did you decide yet?). It’s always great to share my experiences of leaving my last full-time job (3+ years ago), moving to Rails exclusively (2+ years ago), how Allison and I went from two people in an attic to seven people in an attic in about a month… to having an office in downtown Portland and clients around the globe. I’m also always happy to share my not-so-happy experiences throughout the past few years as well. Running a business is hard stuff as it comes with a whole lot of responsibility, which can lead to stress. It was great to know that the rest of the panel has had their difficult experiences. While Rails makes everything feel easy… running a business is a whole different spectrum of challenges. ;-)

At one point during the session the audience was asked, “How many of you are considering starting your own business based on Ruby on Rails?”

The response?

Based off of my extremely scientific calculations (looking around the room), I’d estimate that around 30-40% of the audience raised their hands! Wow. It was fantastic to see that there was that much interest in people starting venturing off onto their own. Imagine… a flood of new companies, competing directly with us… and guess what? I think that’s awesome! Awesome for Rails. Awesome for future startups. Awesome for everyone!

Let’s face it. Rails isn’t going anywhere for a long time.

So, now that the conference is over, questions have begun to appear in my email box. Thank you all for writing. What if you could have a sounding board to throw questions to on a regular basis? Unfortunately, our session only lasted a hour at RailsConf and too many questions weren’t gotten to. Well, I’ve asked the rest of those on the Business of Rails panel to join me on a google group, titled, Ruby on Rails meets the Business World.

If you’re looking to (A) start your own Rails-based business, (B) already run your own Rails-based business, or (©) have business experience that you’d like to share with those in camp A and B… then join the community and start some conversations.

Personally, I’m really looking forward to learning from you all and hope that my experience of co-founding and leading PLANET ARGON can be of benefit to all of you.

/>
[Photo by James Duncan Davidson]{.small}

Josh Knowles just mentioned an article written by David Chelminsky, titled, an introduction to RSpec - Part I. In this article, David introduces you to some of the new language that appeared in some of the recent versions of RSpec as well as give you a complete tutorial on building some specs.

Last night, I had the opportunity to sit down with Aslak Hellesøy and David Chelimsky for a few hours and talk about my experiences of using RSpec at PLANET ARGON and how it’s helped us redefine and evolve our process. In particular, how RSpec has helped us reshape our process of gathering user interaction specifications from our Interaction Design team and business rules from our clients.

If you’re in town and are using RSpec… or are thinking about using RSpec… and see these guys… thank them for all the hard work that they’re doing… and of course, if you run into anybody else on the team.. do the same. :-)

{width=”500” height=”333”}

[Aslak Hellesøy and David Chelimsky]{.small}

Also, by the end of the conference. Graeme and I are hoping to have a small project done to help encourage more adoption of Behavior-Driven Development