"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. We know that frameworks don't solve scalability problems; design solves scalability problems. But 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 -- at present, the core of the scaling issue is language independent (unless a language is exceptionally bad). 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 is not today the only or best place to start. PHP was a practicable option ten years ago, thanks largely to its low barrier to entry, the shortage of peers, and a massive amount of community support that was bolstered by excitement about then new internet technology. 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 appears to outstrip 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).

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." In other words, 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."

We should never tie ourselves emotionally to a particular technology (or 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.