Bill Brown bio photo

Bill Brown

A complicated man.

Twitter Github


The 37Signals crew recently advised against worrying about scalability when designing web applications. It’s the latest in their series of thought pieces on the theme of everything-you-know-about-development-is-wrong-because-of-Rails. They kind of qualified it by saying that their advice applies to new companies. Their point is that you can waste a lot of time preparing a web application for an onslaught that might never come.

Today, Dare Obasanjo, a member of the MSN Spaces team, weighed in about his experiences with that application. He argues that they had to contend with scalability issues from the onset. (I think it might have actually just been an excuse to trumpet MSN Spaces statistics since he’s talking past the 37signals piece.)

Quick Blog, Go Daddy’s upcoming blog product that I’m working on, is going to be operating on an MSN Spaces scale from the onset, so I feel fairly qualified to speak on this issue. I would agree with Dare that premature optimization is generally a bad thing when engaged in at the application level. Whether you use a foreach or a plain old for loop isn’t going to make a difference even though the latter is better performing. I’ve worked with heavy-duty applications and my experience has been that bottlenecks rarely occur at the ASP.NET level.

But an early decision about whether to use stored procedures or inline SQL is going to have considerable impact in the future. And I truly believe that you should design your basic architecture so that it doesn’t preclude optimization for performance later on. If you do things right, scalability becomes a matter of throwing more servers at your traffic. If you don’t, then you’re facing a lot of redevelopment and refactoring in the midst of problems. That’s a situation you don’t want to be in because the pressure makes you do stupid things.

My personal opinion is to know your application’s weak spots, the parts that you think could pose a problem if it became popular. That way, you’ll be able to reduce the amount of analysis you need to do when things start 503ing. If you’ve load tested and done some rudimentary profiling, the potential problems should be pretty obvious.

[NOTE: The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of Go Daddy Software, Inc.]