Jeff D’Urso’s Blog

It’s amazing how you can do something for 25 years, feel like you’ve “seen it all” - then read a book that causes an “aha moment” and gets you as excited as you were the day you started with it.

Oddly enough, I had such an experience when I read “Building Scalable Websites” by Flickr CTO Cal Henderson. And it wasn’t a “geek moment” that you’d expect from a book on website architecture…

It was a validation of a Common Sense Approach to Software and Website Development that I had evolved throughout my career.

In the book, Henderson details all of the various best practices learned while building Flickr’s architecture from startup phase to a website that handles millions of hits a day. And - contrary to popular belief - the secret to handling the growth is more about “pragmatism” than it is about “rocket science”. 

But the part of the book that really hit home was how the team’s choice of development approach drastically influences its ability to get work done throughout the growth of a website. At the two extremes of development approach are what can be described as “One Giant Function” on one side, and “Object Oriented Programming” on the other - and (here’s the key), Sanity in the middle.

Few software development professionals would argue that “One Giant Function” (OGF) is a viable approach to building websites…

OGF (or putting all of the code into huge, quickly unmanageable scripts) is an approach that dominated the early web. It certainly made it easier to “get something up” faster without having to worry about frameworks or infrastructure, but in the medium and long term - it’s a disaster. With the exception of bottom-of-the-barrel offshore sweatshops, you’ll be hard pressed to find a lot of support for the OGF approach, but…

Too Much Focus on Framework can be just as deadly to a website’s success as not enough.

Without any framework, a website is unmanageable over time, but with too much framework - it can get stuck at the starting gate. Teams that overdo framework end up spending 80% of their time “paying homage to the environment”, and 20% of their time solving the business problem (vs the reverse which is clearly a better scenario!)

I’ve seen teams waste enormous amounts of time trying to get some awkward framework to do something absurdly simple, only to get stuck for days or weeks dealing with obscure errors spit out by a framework that required too many i’s to be dotted, and too many t’s to be crossed for any practical project. So if you’re about to build a new operating system, you can ignore what I’m about to say, but otherwise:

Aim for “High Speed, Low Drag”

Whatever “methodology” you use to get a project done, it should pass two simple tests. The “High Speed test” requires that your team is able to get functionality delivered rapidly at all phases of the website’s development. Elaborate frameworks fail this test miserably because they waste the team’s time figuring them out instead of delivering functionality.

The “Low Drag test” requires that you have enough framework in place that the site is easy to maintain over time. I.e., as the site gets bigger and more complex, it doesn’t create “drag” on integration of new functionality. Fortunately, there are several simple “lightweight” frameworks out there that deliver on this promise by creating just enough rails on the development process to prevent “spaghetti code” without slowing the process to a crawl.