Risto

"Twitter. Which goes down, uh ... <looks at watch> ... every 2 seconds".

So began the conversation with my manager.

It was the end of the day and I was wrapping things up when a designer-hoping-to-become-a-developer approached my manager asking for advice on where to begin his adventures in programming. The designer was overwhelmed by the sheer abundance of programming languages and frameworks available (something that nowadays makes even senior engineers shudder when trying to weigh options against deadlines), and was seeking some intelligent guidance. My manager -- who I should mention is a highly capable and conscientious software engineer -- recommended that the designer pursue PHP, to which I raised my arm in a close-fisted protest, declaring my solidarity for all to see, yelling "RUBY ON RAILS." My manager replied with equal fervour, stating "What does Yahoo run on? PHP. What's the biggest site running Rails? Twitter. Which goes down, uh ... every 2 seconds." True. But, a senior Twitter developer stated it clearly in the Twitter interview that database has been the bottleneck. By now we all know that frameworks don't solve scalability problems, design solves scalability problems. Just in case we forgot, it's important to note that it's not the size of the app that matters, it's how you code it -- the core of the scaling issue is language independent. Also, since we're talking comparisons: java used to have the same problems, and it took a dedicated multi-billion dollar company 5 years to fix it.

In any case, Twitter's performance or lack thereof wasn't the issue at hand. If you want to become a good web programmer, PHP certainly isn't the place to start. PHP was a practical option 10 years ago, thanks largely to its low barrier to entry and the shortage of peers. But things change. Dramatically.

Let's move away from discussing particular technologies for a moment, and instead look at best practices. In any sector, proper prioritization is the transcendent issue. In my experience the million dollar question is always maintainability, a concept which single-handedly encompasses and reflects architecture, standardization, documentation, integration, and deployment. In the web software engineering sector maintainability means the following: a sensible and widely applicable application structure (personally, I've been partial to MVC for my web apps for the last seven years), a logical and generic nomenclature (for everything: classes, methods, databases, etc.), a simple but powerful ORM, an easy to use built in interface for automated unit testing (something that I know we all hold dear), a clean and powerful interface for vendor applications and integration of third party applications, built in support for development tiers and thus code promotion workflow (for example: development - internal testing - client side testing - live), an elegant and unobtrusive method of automated documentation generation (preferably requiring no more markup than a simple comment character, '#', to begin with), a generic and intelligent file system layout, and robust source control management. When all of these concerns have been addressed junior people can make better decisions with less guidance, and senior people can spend less time repeating efforts on architecture, design, integration, deployment, naming standards, directory structure, and unit testing.

This list sounds suspiciously like something I compiled after having been exposed to Rails, when in fact it's a list of lessons that I have learned over the past ten years, expanding on it with each new task and professional role that I've held. Many of the concerns above are not limited to software engineering and are applicable to engineering projects in general, and you'll find that achievement, personal contentment, and costs are directly proportional to their implementation. Certainly, robust applications can be developed in Python or Java or Perl or PHP or Ruby or C or C++ or C# or many other programming languages, and bad things can happen in any environment. Interesting things will always be going on, but when approached from a maintainability perspective the combination of Ruby with Rails far outstrips the existing framework offerings in other languages. The most comparable framework that I'm aware of at this time is the Python based Django project, however in my research I found Ruby and Rails to be more coherent, and even more elegant (where 'elegance' is of course a completely useless, qualitative, and subjective measure). With maintainability in mind, here are some interesting if not entirely quantitative visual representations of metrics relevant to the framework debate: new lines of code, active developers, and new projects.

The rationale behind the design of Ruby (and subsequently, of Rails) is the key; "Often people, especially computer engineers, focus on the machines. They think, 'By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something.' They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves."

Technical issues fall into line after human issues have been put into perspective; "There is a pathos in our technological advancement, well exemplified by programmed instruction. A large part of it consists in erroneously reducing the concept of animals and human beings in order to make them machine-operable."

The next statement I'm about to make is idealistic and ignorant, but important: imagine that every application was built in Rails (note: I do not believe that every web application should be written in Ruby or Rails, but it's important to include boundary cases in your examinations when making any decision), you would spend much less time unravelling an application, and could begin development work in short order. Downloading a new program for personal use? No problem, it's in Rails so you know where everything is and how the components of the system interact. New system at work? No problem. New job? NO PROBLEM. There are positives and negatives for all design approaches and technologies, and there is much to be said here, but I hope you catch my meaning and see the significance (and, we haven't even touched on migrations yet).

We should never tie ourselves emotionally to a particular technology (or to any logical pursuit). There is an ever increasing number of options available, and it's important to observe the aphorism "the right tool for the job." Set a deadline for choosing an option and research your options before making a decision, recognizing that every person and project has different intentions. At the end of the day, one way or another, we all have to integrate. "People always seem to be looking for prescriptive, one-size-fits-all solutions. But that's naive in this day and age, when you have so many useful choices. Some tools are better suited to some jobs than other tools."

Technology changes every day, and I've chosen Rails based on the perspective and needs I've developed over the past decade. Indeed, I've selected Rails based on the recognition that perspective and requirements are flexible; fluctuating, regressing, and progressing over time.