Rob and I were recently asked by a client for some help justifying the choice of Ruby as an implementation language for their SaaS product. They were very happy with the results, but wanted to be prepared to answer investor and customer questions about why Rails was a good choice.
One way that I've been talking about Rails is in the context of what I'm calling "The ARC Model": Agile + Rails + Cloud. I'll borrow from my abstract from my talk at BizConf:
The Ruby on Rails Revolution has been one of productivity and efficiency, and has coincided with an equally powerful revolution in the ownership of technological infrastructure. The Rails approach combines agile methods with a highly productive language to allow developers to focus on developing business value, instead of developing plumbing. The Cloud Computing Revolution at the same time has changed the economics of infrastructure, allowing computation to become a commodity not worthy of developer attention, further enabling developers to focus on that which is truly valuable, Innovation. These three factors, Agile, Rails, and the Cloud, combine to revolutionize the economics of software development and information management, in ways that directly impact return on investment.
The question should not be, “is Rails a safe choice,” but “[how long] can we justify the expense of traditional development approaches.”
I think this kind of approach plays nicely to the strengths of SaaS.
In terms of large enterprise deployments, it's early yet: Enterprises tend to be conservative (about Rails as they are about SaaS) so most of the innovation has been in the startup space, with companies like Hulu being good examples of the disruptive power of Rails.
But that said, there have been some major mainstream Enterprise success stories. AT&T chose to dump a failing Java yellowpages effort in favor of Rails, with excellent results in terms of scalability, time to market, code quality, and performance. (There's a decent write-up on BuildingWebApps.)
We are starting to see major companies develop ever more mission/business/revenue-critical components in Rails. BestBuy built Remix, their new public API app, with us using Rails. We have one major multinational client who is rewriting their entire ERP system in Ruby internally. We have another major hardware vendor building new products using Rails.
Large companies tend to be a bit shy about talking about new technology initiatives, and we suspect that most Fortune 500 companies have someone doing Rails somewhere in the organization. There are a number of others we've spoken to who are using the technology to their advantage, but who aren't ready to talk about it publicly yet. But you can also search for job listings from major companies and see how many big companies are hiring Rails developers. We see them all the time.
Hard statistics are harder to come by, but Mark Driver at Gartner projected that there would be 4 million ruby programmers by 2013. We're already seeing the smart companies get huge efficiencies out of these new development models: efficiencies of cost, flexibility, and time to market.
We're very bullish on Agile, Rails and the Cloud. In the current economic climate, the reduction in risk alone is worth the cost of admission. Coupled with the qualitative benefits of being able to out-flank your competition, it's no surprise that we're continuing to see adoption grow so rapidly. The results are too compelling to ignore.
Jeff Sutherland, one of the creators of Scrum, has just posted a new blog entry in his Scrum Log: Pivotal Tracker: Now with a Burndown Chart!
I first met Jeff when we were both presenting on Agile process to a forum of OpenView Venture Partners portfolio companies, and have been a big fan of all he has to say about the adoption and effectiveness of agile practices in the wild.
Many thanks to Jeff for his help to make Tracker a better tool for scrum. We'll keep working with him to make sure Tracker is the best scrum tool it can be.
I just spent a wonderful weekend with 75 of the brightest folks I know in the Ruby community. My hat's off to Obie and the Hashrocket crew for putting together a really great, intimate conference in a beautiful location. It's refreshing to really have to struggle to choose which talk to attend from so many choices at each session. I know too many choices are a Bad Thing™, but the format made for great small sessions, and a wonderful thing happened: Everyone got to really meet and get to know everyone.
Among many others, I had the pleasure of meeting CJ Kihlbom, who nails a lot of why these conferences are so important in his post, The Business Value of Conferences.
It was really pleasant to present to a community of business leaders who understand the value of agile, and who are serious practitioners in their own practices.
A lot of you have asked for the slides from my talk, Agile, Rails and the Cloud, so I've posted them here.
Those of you who thought about coming but didn't really missed out. Come next year. You'll be glad you did.
On Wednesday night we hosted our first San Francisco Tracker Users Group (SF.TUG)
It was a great opportunity to meet more of our users, and hear directly from them about how they're using the product, and share with them some of the philosophy behind it.
We're excited by your enthusiasm and we will definitely make the TUG a regular event here in San Francisco, and we are planning to start one in our New York City offices soon. Please visit the Meetup group to join the discussion, and for more information and the schedule for future meetups.
Last week, Wolfram Arnold of RubyFocus interviewed Edward Hieatt, our VP of Engineering, and Davis Frank, one of our engineers, to try to get at the heart of how you build a scalable software development team.
The interview is posted on RailsLab, at http://railslab.newrelic.com/2009/03/18/scalable-teams-part-1-communication
It's a nice piece. We look forward to the second installment.
I'm very pleased to announce that Pivotal Tracker has won the coveted Jolt Award, in the Project Management category.
I want to thank the judges for selecting Pivotal Tracker above a category dominated by Agile project management tools, and for rewarding Tracker for innovation.
I want to thank the community who have used, evangelized, and supported Tracker, and in particular Obie Fernandez, Ward Cunningham, and Nivi; plus everyone over at Engine Yard for hosting the app.
And of course I want to thank and congratulate the development team and visionaries, particularly Dan Podsedly, Alex Chaffee, Rob Mee, Mark Michael, and Edward Hieatt for envisioning and then building the tool that we've come to depend on.
I'm pleased to announce that Pivotal Tracker has been selected as a finalist for the 2008 Jolt Awards. Thanks to everyone on the team for putting so much care into Tracker, and making it what it is today. Winners will be announced March 11, 2009 at SD West in Santa Clara.
Wish us luck!
For the last year or so, we've been inviting speakers to come visit us and talk about interesting things in the Ruby/Rails space, the agile space, and on topics related to software development in general. We see it as a great way to keep our developers on the cutting edge, and a number of speakers have used it as an opportunity to gather early feedback from our team. We've found the talks we've had to be very valuable to us, and are pleased to share them with the larger community.
To that end, we've posted a selection of our talks to our talks page, and also made them available via the Podcast section of the iTunes Store in both audio and video format.
We've also had a number of panel discussions in our Project Startup and are posting those talks as well.
We'll keep posting talks as we have them. If there are topics you'd like to see, or topics you'd like to present, please email us!
About a year and a half ago, Pivotal Labs started a new practice, focused on product-led startups. It's not the traditional VC/EIR model though. With Pivotal, our clients are the ones with the product vision. They're the entrepreneurs. We focus on bootstrapping development, and getting the engineering effort going. We're just here to make sure the technology works, and that engineering execution doesn't get in the way.
When we take on a project, we like to hit the ground running. We seed the project with an experienced team, ready to begin executing immediately on the client's product vision. As the vision grows and changes, our team adapts. Usually the client will start hiring their development team as development continues. Often, we'll help them recruit and interview. Then we'll weave their new folks into the team, teaching them the code base, and all our techniques as well. We want to make sure that when we're done with the project, their team can move into the next phase of development with confidence, and keep things running smoothly.
When our clients already have an established development team, we weave our developers in with theirs, and co-develop with them. If they're new to agile, we teach them agile practices by doing, as we write code with them. Rather than dropping in with a day-long lecture based on toy problems, and then vanishing into the sunset, we show them how agile works, in their own development environment. We fill in any gaps in their design, modeling and testing skills, and generally improve development practices as we go. Once they're self-sufficient, we weave our developers back out, and move on to the next engagement.
Build-Operate-Transfer
Rob Mee, our founder and CEO, likes to borrow a phrase from the civil engineering world to describe how we engage with start-ups: Build-Operate-Transfer. When an enterprise is first getting started, they typically don't have the engineering resources to get going quickly, and can lose months of lead-time trying to build a team. That's where we come in: Our job is to take our clients from a standing start to a fully functional product, something we can typically do in a few months. Once things are up and running, we're ready to turn over the reins, and let their team run things for themselves.
Flexibility
One thing that's special about us is that we can vary the team size on demand. During the early stages of development, start-ups will often have big fluctuations in workload. We can ramp the team size up or down, depending on development objectives and financing constraints. We can develop at full speed for a week, a month, or a year, then stop on a dime—and stop burning capital—and stop for as long as it takes for the client to close a funding round, or get some traction in the marketplace, or decide on the next round of features. Our clients are done with us when they decide they're done. Their business goals and product needs are always in the driver's seat.
We strive to be a strategic partner for our clients. We are not an outsourcing firm but instead work to get our clients self-sufficient. We believe our approach offers a unique balance between the short term need for execution and the long term need of sustainability.