Thursday, September 20, 2007

Rails, the Enterprise, and Scaling: A Fable

As a respectable restaurant architect for a large restaurant architectural firm, a great local Chef tried to hire me a while back to build a restaurant with a dream kitchen. She told me she wants a 10 burner stove and a 4 bin oven plus a large prep area that the customer can see, like a live Iron Chef (Japan).

She was so into this that she had worked out plans and looked up stoves and prep furniture. I could see this was going to be a doozy of a client. She had lots of 'ideas'.

I pointed out that a stove/oven/prep area like that will never scale to 5,000 meals a day. To my utter surprise, this did not matter to her. She was more interested in having a kitchen that aided the rapid and elegant preparation of 300-500 meals a day, that was it.

She was not hearing reason about that and I'm conflict averse so in order to placate her, I conceded the point because she hadn't thought this through and there were lots of other reasons I could use to dissuade her from her “new fangled” kitchen.

I went on to point out that SHI Thursdays, Pearwasps, and the Olive Patch do not use that type of kitchen setup, and they are quite successful, and lets not forget the granddaddy of them all, the MacDonatello's set up. Their kitchen setups provide tasty meals at a much higher rate than her setup would. Sure, they may take a bit longer to build, and may cost more, but they provide the same quality meal with the bonus of being able to cook a lot more than 500/day if her restaurant catches on really, really big.

It turns out logic was not one of her strong suits. She had a notion that her kitchen environment would make her chef's happier and they would work better. Additionally it would cost her less to build the restaurant and she could use the savings to hire better chefs. (If she really wanted to save money, she could just buy normal straws instead of the more expensive bendy kind that people prefer.) She really didn't expect to make more than 500/meals a day, and she believed she would make a nice living doing that. She said if business was that good, she could open a second one and scale that way.

The obvious inefficiencies of building a whole new restaurant, rather than cook more meals in the existing one seemed lost on her. They clearly did not have too many business classes at her cooking school.

I pointed out to her that OK, sure, her new kitchen layout was 'innovative', and sure the chefs may like it better in the long run, but most chefs are used to cooking in a more standard layout. How are they going to adapt to this new layout in time for you to make a successful restaurant? The odds seemed low. Not surprisingly, she disagreed here. A client who is contrary for their own sake is the worst type of client. She believed that if they were good chefs, they'd figure it out pretty quick. The real talent is in knowing how to cook, not in how to use a specific kitchen.

I guessed the turnip truck she fell off of just pulled away. But I'm a professional and she was the potential client, but I hate to waste people's time and money. Since her idea was essentially experimental, I suggested we build a smaller prototype kitchen and see how it worked. She'd never heard of this but was intrigued. How much would it cost? I told her it wouldn't cost her anything if she didn't like it, and it would only take a month or two, if she liked it of course, the total price of the kitchen would include the effort put into the protoype (which would be thrown out of course). To this day I can still remember her frown. She'd worked in lots of kitchens and was confident in her idea. Also, she was somewhat cash constrained and adding the cost of building the prototype and the opportunity cost of delaying opening by upto 3 months was high for her. Too high.

She thanked me for my time and a week later, informed me she was going to use a smaller firm that fit her needs. I told her I appreciated the opportunity but thank god I didn't have to deal with this high maintenance, low margin client. Especially since we won the bid to redo Infront Chikenhouse's kitchens. Ahh chicken, the original whitemeat. Now that'll scale.


Anonymous said...

"The obvious inefficiencies of building a whole new restaurant, rather than cook more meals in the existing one seemed lost on her."

Since you failed to provide the real-world translation for your fable, I have to guess that this statement either refers to adding more Rails processes on the existing box (e.g., pack of mongrels) or adding a second box and load-balancing. In neither case is the level of effort akin to "building a whole new restaurant". It's not like you have to rewrite the application from scratch to work on the second box.

planetmcd said...

Thanks for reading and taking the time to post a comment.

I'll grant you that this is not a mathematical analogy. The point was to show the absurdity in the way the rails doesn't scale argument is applied to an arguably parallel scenario in an unrelated industry and hopefully be amusing in the bargain.

There is no absolute definition of scaling and depending on what you're doing, it may scale fine or may not. But to argue prima face that rails doesn't scale, therefore its unusable, is a bit absurd.

There's probably lots of stacks that will scale more efficiently (vis a vis some resource whether it money or machines or developers) than rails, but is that solely the reason to choose them. Are there no other considerations? Sometimes no. Sometimes yes.

It would be equally absurd to argue that rails easily scales to digg levels of traffic because a handful of people have succeeded in doing it, but that could be argued for several stacks.

Jeremy Weiskotten said...

I would argue that Rails is more analogous to McDonalds when it comes to adding "chefs", being able to find chefs who can work in kitchen, etc, since Rails projects follow so many conventions. Things are usually in the same place, and they're usually where you'd expect them to be, and one project looks like another. And I don't think it takes long to build new fast food joints.

But I think I'm missing something in the whole analogy...

planetmcd said...

Mr. Weiskotten,
Thanks for reading and replying.

Its stunning you found this post as it was your post and the anonymous 3rd comment that inspired me to sit at the keyboard and type. You presented a rational, balanced, cogent thesis and then that poster dropped the "rails is too slow" canard.

Too slow for what? Processing NASA telemetry data in real time? What if I don't need to do that and never will?

It might be too slow for junior programmers to set up a site that handles 10k/hits a second. But would that be untrue for many other development stacks? But conversely, could a novice programmer pickup Spring or J2EE or .net and quickly put together a workable app? They could in PHP or coldfusion, but unless they were taught or diligent, the likely result is a spaghetti code project.

As you point out, the standard layout of rails apps really allows a programmer to know where everything is going to be and easily get settled in. This is pretty analogous to the boilerplate idea of a McDonald's kitchen. I was more intent on underscoring the point that a good chef would figure out a new kitchen (going from whatever platform to rails) as cooking is the real skill, not knowing a kitchen. If you're a talented programmer, you could program a great webapp in J2EE. But unless you really need J2EE features for your web app, why would you want to. a webapp is going to be great or not depending on what it does. Not what it is "cooked up in".

Perhaps the use of a fable motif was not optimal for a tech audience who tend to think in more logical linear terms, but I heard a bit of wisdom once that "if you want people to be aware of society's faults, point them out. If you want to change those faults, make fun of them." That was my hope here.

Sean said...

At a NFJS conference, Dave Thomas was asked by a Java developer, "Can you dispell the myth that Rails doesn't scale?"

Dave replied, "Sure. Rails scales."

And then he continued with the rest of his talk. :)

planetmcd said...

Sean, thanks, thats a funny story.

Kylia said...

Good post.

planetmcd said...

Thanks for taking a look.