Ruby On Rails Project Walkthrough
by g on Jul 10, 2017
After I posted my "Why Ruby on Rails?" presentation last March, I had several people email me asking how I do business in an "Agile" format. I still eventually want to create my own formula for successful business relationships in an Agile world, but until then I thought I would post a project story (and still dispense some advice). This will walk you through one of Rails Envy's projects from start to finish.
First Contact
Two months ago I was contacted by John Bennett, who runs Free Layouts.com. He sent me an email simply asking if we had availability to work with him to redo Free Layouts.com in Ruby on Rails, from PHP. I let him know that we are always open to new projects, told him our hourly rate, and asked to schedule a conference call with him.
The Conference Call
We talked over the phone and took good notes as he gave me a brief overview of his project. I then told him more about my company and gave him a brief overview of how we run our projects (see below). I ended the call asking him to send me any and all documentation/notes he has on the website, and let him know I'd get him a proposal by the next day.
The Proposal
I love Writeboard for putting together project proposals.
Writeboards allow both the client and I to make changes to a document until we're both happy with it. The proposals I put together have four parts:
- Functionality - A list in plain english which describes all features of a system and how it works. This can obviously get long, but I try to keep things organized. Even if the client sends me a list of what they want, I always end up rewriting it in better english, so that the descriptions would be crystal clear to any programmer.
- Hour Estimates - What I believe each of these features should take to get finished. In this section I always state: "Please keep in mind that these are all estimates, which mean we only charge you for the time that we actually end up using on the task. They include time to fully test the system, and work with you to add any small tweaks you want."
- Total Cost - The total cost based on the estimated hourly rate, with a reminder that we only will charge for the hours we use.
- Getting Started - Here I give the client a pathway to get started with our company. I believe in doing things in phases, so here I pick 2 or 3 of the main features and call it Phase 1. To get started with Phase 1 (and their project), I ask for half the estimated cost of all the tasks in phase 1. I usually try to keep this to between 80-100 hours (2 weeks of work).
Asking for a small cost to get started lowers the risk for both the client and me, and it gives us both a trial session to gain trust.
Getting Started
John was ready to move forward with Free Layouts.com, so I let him know we could get started as soon as we received his first payment. I can't emphasize this next sentence enough: Never start work on a project until you receive some sort of payment.
John promptly sent payment and once received I emailed him a receipt and started coding his project. The key to successful projects (for several reasons) is communication, so here is we ran his project (and how I try to run most products):
- Monday Conference Call - Once a week John and I talked on the phone about the project. We went over what happened the previous week, any comments/tweaks he had, and I set some goals for the current week. No long term goals, just "here is what I think we can accomplish this week".
- Wednesday / Friday Status Emails - Twice a week I would send out status emails to John. These would include a detailed list of all the work done on his project (which he could immediately try on the dev server), as well as how many hours were used on the project (Member System X / 40 hours).
- Constant Request for Feedback - I always encourage my clients to give as much feedback as possible. If requests for changes were small enough to fit in the initial contract I just did them. If the request for change was bigger, I would email John back letting him know it would take X hours to do the work, and ask for the green light.
I don't feel comfortable ever spending more hours on a project then the client has pre-approved. Thus, even small tweaks need to get approved if they lie outside the scope of the initial project estimates.
Leading up to Deployment
Recently I got smart and started putting down hours in my project proposals for "Server setup, configuration, and optimization". For John's project this was 24 hours, and I used all of this time. What did this consist of?
- Server Setup - Setting up Subversion (with svn_dav), Trac, and Apache/Mongrel on RailsMachine. I cannot count the ways I love RailsMachine for my clients websites. They may cost a little extra, but they're worth every penny.
- Caching / Optimization - One of John's concerns was the speed of Rails since his website gets over 20,000 unique visitors a day. I planned on doing some caching, but before diving in I decided to run some Benchmarks. I downloaded the Benchmarking with Httperf Peepcode, learned how to do benchmarking, and jumped right in.
I ran httperf on a few of the main pages, and averaged about 28 requests / second (that's 2.4 million hits a day). For comparison, I ran httperf on his old PHP server, and I got about 26 requests / second. w00t, my rails version was faster! I realized that the website was already fast enough for what John needed without much caching, but I still decided to page cache the front page just to be safe. With Page Caching in place the front page went from 28 requests / second to 1100 requests / second or 95 million hits a day (that's 1/3 the population of the United States). Page caching rocks! - Pushing the site live - Last Wednesday we disabled the logins on the old PHP site, migrated the data/files, and then pointed the DNS at the new rails server (this way the average user didn't see any downtime). There were a few small errors as people came over to use the new site, but since I was using Exception Notifier plugin, I was emailed the errors as they occurred on the live server and fixed them within minutes.
Migrating the data from the old site probably took the most dev time here. I put together a rake task that would automatically load the legacy data into the new database schema, transfer all the old file uploads, unzip all the file uploads for the live previews, transfer images locally and generate thumbnails, and finally upload user files to Amazon s3.
The site has been running smoothly since last Wednesday, and John's pretty happy with the work we've done on the project. His site is probably the highest traffic rails website I've ever created from scratch. If you like the look of it, do me a favor and Digg It.
Comments
Sorry, comments are closed for this Post, but feel free to email us with your input. We'd love to hear it.
RSS
Archive
Nice article, sounds very similar to the way we do it. Time estimation is probably one of the hardest things I have to do on a day-to-day basis… how do you account for the (hopefully infrequent) times when you underestimate a feature?
Some clients want a guarantee that it won’t go more than 10% over the estimate… do you think that’s practical? Eek!
Ed
Good overview, that’s mostly how we do it except that we almost always use user stories for the requirements.
Ed, a guarantee that you won’t go more than 10% over the estimate is nonsense. Just make it clear that you’re giving the best estimates you can and that you’re not going to go more than 10% over without getting feedback from your customer first.
If they keep insisting on a limit, they’re really just looking for a fixed-price, fixed-scope contract and you should probably just walk away.
I don’t typically Underestimate features.. hehe.. But if you’ve waited until the day before something is due, and realized something will take an additional 4 hours, then sometimes you just have to eat it.
Typically the reason tasks take longer then estimated is because the client wants more revisions / changes. This is where you have to be VERY careful. Obviously you have to leave room for a certain number of tweaks in your estimates, but if doing too many will bring you over the estimate, then you have to ask for more hours.
Asking for more hours is always okay as long as you fully educate the client to the situation and ask well in advance (as opposed to the day before it’s due), they should be responsive. I’ve had to do this a few times.
If the client has a limited budget I might say: “If you want this feature we can spend an additional 3 hours on it, or remove another feature in another part of the system to leave room for it.”
I typically guarantee that I won’t go 0% over the estimate, assuming that the project doesn’t move out of the scope of my writeboard. And well.. It ALWAYS moves out of the scope of the writeboard…
As we all know.. clients 99% of the time want additional features. I try to educate my clients best I can at the start. “As soon as you start playing with the system, you’re going to want to make modifications and improve it. This is only natural to create a finely focused website.”
If a client is a stickler to the contract price, then sometimes you need to be too. The second they ask for a revision which is outside the scope, you have to let them know they’re outside the contract. Sometimes another good idea is to limit their rounds of revisions. You’d say “After we finish the phase you can send us two emails with revisions you want, any additional revisions will be outside the contract.”
Sorry if it sounds like I’m preachy.. ;-)
Wow,
I agree with much of what you have to say concerning fielding client changes. We also add into our agreement (that we and the client sign) that anything outside of the scope is billable, will impact timelines, and will require signed estimates. Our clients are highly responsive to this practice.
For us, the keys in good client management are flexibility and (as you mention) education of the client up front. People ask us if we practice “agile.” I normally answer that be telling them our definition, and then asking for theirs. Making sure we are on the same page up front, and that the client can work with the process we have in place, is super important. If all of the planets are in alignment, then all is well.
I’m beginning to lean more towards an unspace approach for all my projects. It makes for an easy sale and I haven’t gotten burned yet. I suppose only time will tell :)
That’s great that you’re using Writeboard. Do you take advantage of Highrise or Basecamp? Both would seem extremely valuable for projects like this.
Such a great post with great insight on just how well of a job you guys do.
A very nice article and some great comments too.
Thanks for the plug. I respect you guys that are brave enough to do consulting work like this as I could never get the swing of estimating well and keeping clients happy!
Great insite on your business end. I would have done likewise
Thanks for this awesome post. It sounds like you’ve got a great process in place that any freelancer / small business could use. I’ve definitely bookmarked this entry.
Do you have tools, metric or some data to digg into to estimate tasks? If yes, how do you get feedback of each project to collect new information?
IMHO is quite strange to say ‘it would take me three months’ to a client without backing it up with some figures.
I know its just a briefing but you said you did some benchmarks and decided to cache pages. What other decisions regarding scalability did you take? What was the server architecture and the database system selected? how did you plan to manage the client sessions?
I am not a php advocate but ‘my rails version was faster!’ smells bad to me since it doesn’t look a fair comparison (everything was the same except ror instead php??)
thanks for a great article! previously did it with emails and other old-school systems, will give writeboard a try.
now, i am very curious on how you did 2.4m hits a day. can you elaborate on that? how many mongrels do you have? what are the server’s specs? any hint on how to get a super-fast rails app?
i am also curious about exception notifiers and emails handling in general. i know sending an email with rails takes quite some time. do you send them to a backgroundrb queue?
heri - ARMailer is a good way to send emails in the background. There is a writeup of it in recent Peepcode Best Practices PDF, which also has examples of using 2 queues (one for important emails, like signup confirmations, and a “whenever possible”-type queue for things like Newsletters or what have you, which don’t matter if it takes days to get there).
ARMailer just sticks the emails in the DB, and sends them using a cron job.
You can improve the front page’s load time by turning on asset hosts. Just add DNS CNAME entries for asset1-4.freelayouts.com pointing to freelayouts.com then uncomment the asset_hosts config environments/production.rb.