Obie Fernandez

Hey Web Startups, Hire Consulting Firms On The Cheap!

So you're an entrepreneur and you're doing a lean web startup using Ruby on Rails. You're teaching yourself Rails and proud of yourself for going at it alone and not spending a bundle of cash. You know that you can't afford to hire a world-class shop like Hashrocket, Thoughtbot or Pivotal Labs to work on your project, because the minimum project budgets they are interested in are in the six figures.

Incidentally, this post is strictly my personal opinion is in no way endorsed by or representative of anyone at Hashrocket, ThoughtBot or Pivotal.

Well, allow me to let you in on a little secret. You can absolutely work with those firms and maximize the benefit provided to you for as low as a couple thousand dollars. Just not in the way that you might think. And it won't be the way that they would prefer to work with you, but they'll still do it.

See the jars above? Consider the container to be the size of the available billable hours in a month. The large rocks and pebbles are current projects. It is impossible to fully utilize the space available unless you start adding smaller rocks and pebbles and eventually, grains of sand. Even the busiest consulting shops always have small amounts of utilization available. It's the slack in the system, time for people to relax, the empty volume of the jars. Despite the importance of slack, the profits of a consultancy live and die by utilization. When I was in charge of Hashrocket, which was generally busy, do you think I stressed about utilization? Yes I did. Every fucking week of the year. It's one of the reasons I got out of the consulting business. Will most consultancies take advantage of opportunities to bump up their utilization with profitable small work? Yes! The trick is how to make them do it, even if they resist at first.

Before I describe that trick, let me explain the backstory that provoked this post: Last night I got to know a couple of young entrepreneurs from NYC, Chris and Philip. They are working on an interesting little web startup named Meeteor. It's technology driven. During a conversation about testing, Philip told me that he spends a couple hours manually testing the app everytime they're ready to do a deploy. They don't do any automated testing, because they don't have the time to figure out how to do it well. My ex-ThoughtWorks friend Kurt Schrader was present and we did the requisite head shaking and tsk-tsk-ing about their failure to test their code. But the truth is, if I were in these guy's shoes I would probably do the same thing. It takes years to get really good at TDD and integration testing to the point where it doesn't slow down your progress tremendously. Sure, without tests you'll build up technical debt to the ceiling and the whole project may eventually collapse under its craptastic weight, but in the meantime the perceived slowness of figuring out how to test your stuff will demoralize and destroy your productivity. It's a no-win situation for newbies.

My advice to the Meeteor guys (and to all of you in similar situations) is the secret alluded to above: Hire help from Hashrocket (or any other competent firm) but only for a day or two at most. And I'm going to tell you exactly how to do that:

1. Call the shop up and get a decision maker on the phone. Convey that you know exactly why you're calling them and what you need.
2. Request their top Rails (and/or testing) expert for 1 day. State right off the bat that you're willing to pay their full hourly rate for those 8 hours. If you can travel to where that person is then state that you're willing to do so. Otherwise offer to pay for reasonable travel expenses to get the expert on site with you for a day.*
3. Be insistent and don't lowball them on the price. Even if they want a substantial markup on their normal rates it will still be worth it. Be prepared to have to wait a few weeks for that person to be able to take a day off from their current project. Be prepared to wire half the money up front as a deposit or even pay in full upfront.
4. Make sure the contracting goes as smoothly as possible. Do not involve your lawyer in the paperwork or negotiate on price. Do not keep anyone on the phone for a long time answering questions. Anything that makes the sale time-consuming to close (read: expensive to handle) will make the whole gig unprofitable and they will rightly tell you to get lost.
5. Once you are working with your expert, sit as a pair at the computer with them but make them drive the entire 8 hours. Do not touch the keyboard at all. Your aim will be to get the expert to tackle as many sticky problems as possible in 8 hours. Dedicate the first hour to making them set your development environment up properly, because it the way you have it right now sucks. Don't let them try to teach you VIM if you use TextMate, like don't even spend 5 seconds on that, but let them use whatever they normally use. Do not do any storycarding or get any consulting about your consulting process whatsoever. Remember that you're not there to learn directly from your expert. What you are there for is to direct the work, answer questions about the domain and keep your expert focused and productive for the duration of the 8 hours. That includes getting coffee, snacks, cigarettes, whatever. You are there to get them to do as much work on your app as possible and you will learn later on from analyzing their work.

* Right now (Mar '11) a total budget of $3k is probably very reasonable for what I'm describing.

In the case of my friends at Meeteor, they'd want their expert to implement some cross-browser selenium integration test cases. All they need is one of their most difficult ones, because once they have the scheme setup and one or two examples to draw from, they're smart enough to figure out the rest themselves.

Remember that the point of this technique is to buy as much great coding as possible in a day or two. Then you can use the results for inspiration for your own hacking. This technique works with any superstar programmer whether they are coming from a shop like Hashrocket or not. Shop refuses to work with you? Hire one of their guys for a single-day side gig! In Europe and using Mongo? Throw a couple thousand at my friend Durran to pair with you for a day. You get the idea. Just make sure that the person you hire works full-time as a programmer every day. This scheme wouldn't work with someone like me; I have plenty of depth, but slow velocity since it's not what I'm doing everyday.

The productivity boost you can get as a newbie developer from working a true expert for just a day (or two) is exponentially more valuable than what it will cost you in cash.

Google Probably Knows What Crap Results Are

A post by Jeff Atwood bemoaning the state of Google's ranking system caught my attention this morning. I have had similar feelings about a decline in the quality of Google's search results. Jeff and others are wondering if the failure to give priority ranking to primary content sources is due to limitations of Google's search algorithms. I suspect that Google has at least some idea of good versus bad results, based on observations of their Alerts system.

For obvious reasons, I've had an alert set on the phrase "The Rails 3 Way" for months. Less than 2 weeks ago, I noticed that there was an option for Google Alerts for receiving All results vs. Only the best results. Out of curiosity, I changed over to All Results.

What a difference! Instead of a few interesting alerts per week, I started getting up to dozens per day, almost all of which were some variation on

Google knows that stuff like this is crap, otherwise it wouldn't have an option in Alerts to filter it out. So the question is: Are they not taking greater action against spammers because it would hurt their bottom line? And, if so, is that evil?

I'm curious whether Jeff has any similar and/or relevant observations using Google Alerts, because the phenomenon I'm describing here is not exactly the same as what he's complaining about. And to be fair, I went ahead and did a search for The Rails 3 Way pdf and the book's official source is #1, with fileshare services not starting until #3.

Stocking Stuffer: Mental Notes

I've now bought a few of these Mental Notes decks for the Hashrocket offices. Each card (52 in all) has an insight drawn from psychology that can help you with brainstorming and problem solving. They arrive in an attractive faux leather box and the whole package seems like a great little Christmas gift. I'm not making any money from this referral -- I just think they're great.

Mental Notes (about $50 incl. shipping to US destinations)

Get the first 7 cards as a PDF download

Competitive Research Series: Part I

Early this year, I commissioned a competitive research project with the goal of producing real insight into how other web design and development shops out there do business. The results were interesting, to say the least, but due to time constraints I haven't been able to do much with them. I'll be sharing highlights of the data with you over the coming months, starting with this introductory blog post.

First, an explanation of how the data was gathered. First we helped our researcher, a potential entrepreneur with a good idea, to flesh out his web startup concept (involving social media and e-commerce). We crafted the scope of the project to correspond to the type of complex web application work that Hashrocket has designed and built on budgets ranging from 100 to 500 thousand dollars. The project details were crafted well, probably beyond what was necessary in order to do the study.

Over the course of a month, our entrepreneur painstakingly contacted a total of 103 web design and development companies, primarily via email. 54 of those companies followed up to some degree or another, ultimately leading to in-depth conversations with 42 of them. That leads to one of the first eye-opening revelations of this study: Almost half of the companies we contacted didn't follow up properly or at all. In fact, about 6% of our initial contact emails bounced! Has that much of the industry gone out of business this year? Or is email that unreliable a contact method?

It is difficult to discern whether the firms that ignored initial contact did so because they were careless or simply too busy. Perhaps the work didn't interest them? One well-known firm had an auto-reply message to the effect that they were too busy to respond to anything other than urgent requests, adding that their lead time for starting new projects was at least 3 weeks or more. Ballsy.

I will not be identifying any of the companies researched, although I will say that many well-known shops were on the list, including one behemoth that ended up being excluded from much of the results by merit of being such an outlier (ahem). The list of companies to contact was first drafted by naming the shops we know off the top of our heads, then enhanced with shops found via Google searches and a variety of online resources including:

    ⁃    FirmList.com

    ⁃    RailsDevelopment.com

    ⁃    Sortfolio.com

Our entrepreneur purposely tried to contact providers with a variety of technology specializations (not just Rails shops) and did not express a preference for a particular technology, instead asking the shop to give their preference. As you can see in the graph below, we were able to include a healthy number of PHP and .NET shops.

Somewhat surprisingly, but perhaps due to our small sample size, none of the shops expressed a preference for Python. We also were not able to talk to that many Java shops. Perhaps Java really is losing steam as a mainstream web technology?

The size of the companies studied varied quite a bit. In a future entry in the series I plan to analyze a bit more carefully the smaller end of the spectrum, but for now I'll simply give you a graph showing the distribution by headcount.

We also got data on the years in business of the companies contacted and what kinds of people they employ.

 

By itself, the years in business distribution seems somewhat even and perhaps doesn't say much, but I hope to break down some of the other data in relation to maturity of an organization and hopefully yield some interesting results.

On the other hand, the employee type breakdown did surprise me. The vast majority of the firms we spoke with claimed to employ only full-time employees (FTE) rather than a mix of FTEs and contractors. Even less used only contractors, with a significant fraction of the mix being shops with a main market presence and offshore development resources. 

 

When we asked companies about the average years of experience of their developers, most said "it varies," which we took to mean that junior developers would be involved. Fifteen percent gave us a number between 1 and 3 years, which doesn't inspire much confidence! 

 

Over half of the companies we spoke with were willing to share annual revenue figures, with the rest declining to answer for confidentiality reasons or simply not knowing.

 

We're guessing that many of the numbers we were cited were make-believe, because the variety of revenue figures was very surprising, especially when analyzed in conjunction with head count to derive per person revenue numbers. Could the spread in profit margins really be that wide?

 

 

The next entry in the series will delve into hourly rate data, which I'm sure you don't want to miss.

 

Excellence Is In the Details: GMail EOM

It always gives me such great pleasure when I notice excellent attention to detail in software that I use on a daily basis. In this case, it's a detail that I've noticed before, but never have heard anyone talk about.

Every once in awhile I send someone an email with just a subject line. If you enter a subject in GMail and hit send, you'll get a warning dialog asking if you really want to send without a body.

However, if you follow the convention of suffixing your body-less subject line with the string [eom] and hit send, then GMail doesn't bother prompting you with the warning dialog, because someone on that team knew that EOM stands for "end of message".

Excellence is in the details. They don't always have to be visible or even talked about. In fact, when you discover those great little details in practice it can really be a really delightful and loyalty-building experience.

I'm Cuckoo for Chrome Frame

Don't know what Google Chrome Frame is yet? Watch the following short video first...

This is such awesome news that I'm practically besides myself with joy. I think web app developers should make a concerted effort to push adoption of the Chrome Frame plugin, just like Adobe's flash player plugin.

I tried it today on an app that I'm working on which looks like hell on even modern versions of IE. Worked seamlessly.

I can see developers of wide-audience consumer facing sites still facing real resistance towards dropping support for IE6. However, corporate IT and web apps written for the "enterprise" should have little trouble getting this plugin adopted.

Put the following meta tag in your app to activate Chrome rendering on IE:

<meta http-equiv="X-UA-Compatible" content="chrome=1">

Workaround to Get All Your Twitter @Replies

Twitter's show me all @replies has not been working, which means you don't see people's replies to you unless you follow them. If you have a high ratio of followers to people you follow, you can really come off as a dick because of this bug. Thanks Twitter!

Luckily there's a workaround involving Tweetscan

Uploaded with plasq's Skitch!

Do a search for your Twitter username and subscribe to the resulting dynamic RSS feed. Problem solved. Hopefully Twitter gets their act together soon, though. Even though their scaling issues have nothing to do with Ruby on Rails, they still give plenty of FUD-fuel to the haters.

MagLev is Gemstone/S for Ruby, Huge News

...and I suspect it will be a hugely disruptive force in the Ruby/Rails community in the future.

Holy shit! - Antonio Cangiano (after seeing the benchmarks run)

Avi Bryant seems to be leading the project and it's only 100 days old (and how did it stay secret so long?!?) However, since it's based on the mature Fast VM used by Gemstone/S, they're already blowing away Ruby MRI 1.8 benchmarks with 8-60x speed increases. Mention was made of cooperating closely with Rubinius team to make sure that their implementation runs all the Ruby specs, and is truly Ruby and not a fork.

When MagLev is widely available, it basically means that there will be a truly enterprise-class option for writing trading systems, logistics and other large persistent object-heavy systems in Ruby. The shared memory cache (basically a large OODB) holds up to 17PB and has transactional capabilities and automatic synchronization. According to Avi, there is a strong commitment to making sure there are good ways to use Rails on MagLev -- ActiveRecord, which no longer would be truly needed, could still be used (with the exception of find_by_sql, of course).

I'm dying to play with this stuff. Ditching relational databases is a no-brainer for most of the projects that I've worked on in the last 5 years.

SAP Sued for Typical Ghetto Behavior

So... when me and my friends talk about the "bar being set so low" in this industry, we're not talking simply about programmers. Stupid, crass ("ghetto", if you will) behavior is endemic at all levels, and even at the biggest players. Case in point, SAP getting sued to the tune of $100 million by Waste Management over a failed enterprise project. (full article via cote)

The trash-disposal giant Waste Management is suing SAP, saying top SAP executives participated in a fraudulent sales scheme that resulted in a failed ERP (enterprise resource planning) implementation.

What makes this case interesting, in my opinion, is that the "fraudulent sales scheme" that SAP is accused of doing is a well-known marketing tactic used by practically every software vendor I've ever known, and is probably familiar to you as well. Read on...

In 2005, Waste Management was looking for a new revenue management system, according to a company statement. "SAP proposed its Waste and Recycling product and claimed it was a tested, working solution that had been developed with the needs of Waste Management in mind,"

Emphasis mine. They claimed it was a tested, working solution! Further, they promised to implement it throughout Waste Management in 18 months. There must be huge logistical challenges and biz-process re-engineering (BPR) factors to account for in such a deal, but 18 months is probably a reasonable time-frame to get a working, tested solution implemented. However, writing plus implementing in 18 months, for such a huge company is of course a whole 'nother story!

"From the beginning, SAP assured Waste Management that its software was an 'out-of-the-box' solution that would meet Waste Management's needs without any customization or enhancements"

Wow! No customization or enhancements! How do you convince skeptical purchasing managers that such a bold claim is true? (Here's where I start chuckling, knowing how common this practice is)

Waste Management said product demonstrations by SAP prior to the deal employed "'fake software environments, even though these demonstrations were represented to be the actual software."

If you're in the business of selling enterprise software, you kind of have to go read the article, because it is a priceless account of how to really fuck up a major deal like this.

Waste Management ultimately signed a sales pact with SAP on Oct. 3, 2005, according to the court filing.

The charade about fully-functional and tested software collapsed immediately.

"Almost immediately following execution of the agreements, the SAP implementation team discovered significant 'gaps' between the software's functionality and Waste Management's business requirements," it states.

I guess deep-down inside, it's this sort of stuff that drove me away from the "enterprisey" side of the industry. For all the talk of pragmatism and being lean, and Agile, this sort of thing is just still too common.

"Waste Management has discovered that these gaps were already known to the product development team in Germany even before the SLA was signed. Instead of admitting what it knew at the time -- that the software lacked basic functionality to run Waste Management's business -- SAP undertook an elaborate fraud to perpetuate the original fraud and to recover additional money from Waste Management."

How do you cover up fraud on this scale? Blame the client of course!

Members of SAP's implementation team blamed Waste Management for the functional gaps and submitted change orders requiring that Waste Management pay for fixing them, according to the complaint.

We all play our part in the grand drama of IT, behaving in ways that improve the industry or lead to fiascos like the one described above. The client is not always right, and I'm sure Waste Management played into the fraud to a large degree, with clueless managers and unreasonable expectations. The onus is on us, the technology providers, both at the executive level and below, to stand up and be honest about what can and cannot be accomplished, and risk our jobs if necessary. That's courage, although you have to admit, that given the red-hot demand for IT talent currently in place, it might not actually take that much courage to stick to your guns.

Big Name Companies Using Ruby on Rails

Woke up this morning to the following email request from the CTO of one of Hashrocket's big, important clients:

Can you give me a list of big name firms that you know are using Ruby on Rails for major projects. Need it by this afternoon for an important meeting with top management.

I scrambled together a response, including some advice from folks that responded to my query on Twitter (thx!) After some reflection, I realized that it would make a good informative blog post.

First of all, lots of people pointed me to http://www.workingwithrails.com/high-profile-organisations, which lists the following firms:

Sing ♫ one of these firms is not like the other ♫ while you're reading :)

• amazon.com
• BBC
• CapGemini
• BPN
• Cisco
• C|Net
• EA (Electronic Arts)
• IBM
• JP Morgan
• NASA
• Oakley
• Oracle
• Siemens
• ♫ ThoughtWorks ♫
• Yahoo!

In addition to the list above, there's a number of companies where I have direct, or reliably indirect knowledge of Rails adoption through my friends and associates:

• John Deere
• New York Times
• NBC
• Barclays
• LA Times
• Chicago Tribune
• Orbitz
• Google
• Turner Media
• Limewire

For good measure, I also mentioned http://rails100.pbwiki.com/, which tracks high-traffic consumer-facing websites that corporate-types won't necessarily recognize by name, but that for sure handle millions and millions of visits per day. The top ten list on that page (and corresponding Alexa rankings):

• twitter.com [642 !!?! I thought it would be higher]


• scribd.com [940]


• blingee.com [1170]


• yellowpages.com [1734]


• penny-arcade.com [2069]


• 43things.com [4190]


• kongregate.com [4488]


• pitchforkmedia.com [4740]


• projectpath.com [5041 One of the Basecamp hostnames]


• funnyordie.com [5089]

What big-name companies do you know about where Ruby on Rails is gaining traction and adoption from the grassroots level on up?