As I suggested in an earlier post, I’d like to discuss the choices that we as software developers have when it comes to implementing applications. These choices can be as fundamental as your programming language, your choice of tools, such as your IDE, or the libraries you use, such as your ORM or AJAX choice. There seems to be a number of people who seem embarrassed by the amount of choice available; they believe there should only be one correct choice of a programming language, IDE, application framework, etc., and we should be able to objectively decide what these choices should be and use that set of tools from now until we retire. Of course, the choices they have objectively chosen are correct, and if you believe otherwise, then you should be treated with a mixture of pity and scorn.
We have all seen these religious battles rage. They are not new, and they will continue to flourish every so often. Most recently, the theater of combat is Ruby on Rails (RoR) vs. Django and usually close on its heals: Ruby vs. Python.
I believe in all the cliches that we know are true, and that cooler heads eventually interject into these debates. There is no one-size-fits-all solution, you have to choose the right tool for the job, etc. Yet these debates still happen, and its reasonable to ask why. To me, it seems like there are two groups of people that engage in these debates–or at least two that I have been able to identify so far. There are the developers who have become old and tired before their time and don’t want to keep learning new approaches every few years. For example, I work with someone who still programs exclusively in C and claims that OO itself is wrong headed (“isn’t it all just subroutines in the end?”). This poor quixotic soul is still fighting a battle most people abandoned long ago.
Then there is the exact opposite, new developers who are stubbornly enamored with whatever their first love happens to be, or with whatever they were first taught, unable to view the world without that filter. Another co-worker, a strange bedfellow of the older C programmer, graduated recently from a CS department that used C for everything, because they believe (and I tend to agree to an extent) that if you know C, you are well equipped to learn whatever the current practical environment is in your first real job. The graduate missed that part of the lesson however, and refuses to learn a new language arguing that the value of any application is measured solely by its performance (wrong), and that nothing competes with C in this area (wrong again).
I see common ground among the two. Both are too comfortable with their current knowledge and toolset. Both have control issues. The old-timer sees that the world is constantly changing and is trying desperately to stop it as much as he can. The graduate is too inexperienced to know that the world changes constantly and mistakenly believes that what she has been taught is the one right way to develop software instead of a relatively new way. In the face of change, a favorite tactic of each of these types of religious technology warriors is to fix upon a perceived area of superiority of their tool, one they believe nobody can argue against, and argue that that area is the most important criterion when it comes to judging a technology.
But the truth is that our environment is constantly changing in every area of our lives, and in the world of technology that change is even more pervasive and rapid. This change is in fact the key defining characteristic of technology and why technology is beneficial; Technology is only valuable insofar as it evolves. As much as the RoR warrior loves his tools, he must recognize that it will have its finite useful lifetime just like every other technology, and he will have to learn something new at some point or become irrelevant. That new thing may not be Django, but there will be something. And, the truth is that even within your current chosen areas of expertise, change is constant; RoR and how you use it constantly changes, Ruby and the best way to implement things in Ruby changes, your IDE and how you use it changes, your libraries, the list goes on. The way I write a Web application in Java today (Spring, iBatis, etc.) is completely different than how I did it three years ago (Struts, OJB, etc.), and three years ago, I wrote Web applications in Java very differently than I did three years before then (vanilla servlets and JSP). I expect that in three years, it might change again, as I value using the current widely adopted best practices at any given time. So what would it mean to argue that Web applications should be written in Java? If you are not prepared to deal with these inevitable changes, in fact if you are not prepared to “embrace change” then you are simply in the wrong line of work. Consider blacksmithing.
RoR is a truly great framework, agile and a RAD approach, and it is the “killer app” that gave Ruby–a great language–the recognition it deserved. I don’t think I have ever seen quite the revolution I have seen with RoR: people are adopting one of our most fundamental technology choices, the language they use, based on the power of this framework. And this has been done not based on hype as the Java revolution largely was, but is instead based on people actually using the framework with success. And in the process, the RoR folks have greatly evolved some of our most fundamental concepts about how Web applications should be developed.
There are probably only a few religious zealots in the RoR community, or any other for that matter. It probably only seems like there are more because they are so much more vocal than the rest of the community. But of those that exist, they seem to fall into the category of the relatively inexperienced developer who cannot distinguish between building a Web application and using RoR to build a Web application.
I tend to see Django more as a sibling of RoR than a next generation of it, although when I explain it to management and inevitably have to present a gentler explanation, I often describe it as the next generation of RoR. I think the key thing to realize here is that fundamentally, RoR and Django represent choices that we as software developers have. In the realm of commercial software, there are many choices for any given application, even in areas where one vendor is dominant, and this competition is traditionally viewed as a good thing, so why isn’t this choice considered good in the open source community? Obviously, there is enough talent to go around on these projects. So, if I want to be part of the RoR fun, but I don’t want to learn a new language and a new framework, Django or Seam, or something else might be just what I’m looking for.
Of course, its a good thing to be an advocate for your open source technology of choice, and this advocacy can be more important in some areas as the criteria for the choices we make can vary considerably. For example, I suspect a developer is more likely to know more than one language than to know more than one RAD Web framework in each of those language. If I am developing a more general purpose program, I can choose a language that I feel is the best tool for the job, but among RAD Web frameworks, the criteria is a little different, and I am more likely to learn one framework in one language that I believe may be the best choice overall for that type of application and my skillset rather than learn multiple frameworks and make the decision of which is the best for me to use on a per job basis. The decision of which IDE to use is again based on its own set of criteria.
But the point that I think the religious warriors are missing, and what gives open source developers such a tremendous advantage over the commercial market is the fact that we are cooperative rather than competitive. More than in the commercial market, choices strengthen the community, not weaken it. For example, we can openly learn from each other, even to the point of sharing code. Another debate that sometimes takes on religious overtones is Django vs. Turbogears, which is especially ridiculous given the opportunity for cooperation among two mature Python projects.
I have seen suggestions of Django and TurboGears merging, despite what I see as their pretty fundamentally different approaches. But even if the two projects merge, it is only because people have recognized the value of each, and they would not have recognized that value if the projects had not developed independently of one another. Imagine what might be lost if an enterprising RoR developer with a novel idea decides not to pursue creating a “rival” framework to RoR because of the dominance of RoR and the zeal of some of its proponents.
Having options is better than not having options, even if you ultimately decide to use only one. However, I would argue that a developer is more valuable to his employer or clients when he has a significant breadth of knowledge as well as depth. This is perhaps clearer with consultants who work with multiple clients. As a consultant, I have often chosen PHP as the right tool for the job when ease of deployment and a low support learning curve are chief considerations, even though Java is my primary language and has its own advantages. Java may not be the wrong answer, but PHP is more right. I also work as an in-house developer, and in that environment, I also find that being knowledgeable about many approaches makes my employer happy and increases my chances of overall success on projects. And the more you broaden your knowledge the easier it becomes, so that instead of trying to explain why I would rather use, say, RoR than Django on a project, which would just sound like lame excuses to my manager, I can confidently agree to jump into projects for which the platform is determined by external factors and may not be in my first choice of environments. I like to say “yes” to people rather than give excuses, and having the confidence to say “yes” feels good, and gives me a reputation as someone with a “can-do” attitude.
Learning new languages, new frameworks, etc. gives you a broader, more balanced perspective and can teach you unexpected lessons. Before I learned PHP, I bought into the Java snobbery somewhat; why would I learn PHP when I can do anything I want in Java? This attitude wasn’t wrong so much as it was short sighted. When I took over a client’s Web application that was written in PHP, and began to learn PHP’s approach to Web programming, I immediately realized I was gaining valuable insight into the work I had done in Java, and I returned to Java Web development wiser and more open to novel solutions. Learning something new is never a waste of time.
The in-house programmer is often on the watch for “multiplying architectures” and might view what I am proposing as constantly chasing after the newest hyped technology without properly considering supporting all these approaches. I think this concern is overstated. The larger your toolset and the broader your knowledge base, the better prepared you will be to support more systems. As I have already mentioned, often the opposite problem is a greater risk to an organization–those who refuse to learn new technologies become less valuable because learning is an investment, not a cost. New tools can save time and give you the ability to do more and far outweighs the typical learning curve, and learning curves tend to shorten as your knowledge broadens anyway. As agile developers, we should be smarter about the economics of software development and properly factor in time and knowledge into our equations.
Of course, one exception to what I have said is ColdFusion. If you choose to do anything in ColdFusion, you are woefully wrong.