Ravi Mohan's Blog
Sunday, November 04, 2007
The Algorithm Quotient of a Software Project
Still thinking of the DARPA Car Races, it strikes me that a project's dependence on algorithmic innovation for a successful outcome is in direct proportion to its "interestingness" froma developers point of view. Think about it. All the cars that autonomously traverse 160 miles of desert or travel through an urban environment while obeying traffic rules have essentially the same hardware. The difference in performance is about how algorithmically sophisticated the *software* of each car is. On the other end of the spectrum most "enterprise" projects are algorithmically trivial (I said "most" so if anyone's ego out there is tied to his knowledge of JSP or whatever, spare me the righteous indignation) and the most complex data structure used is often a hashtable. I don't think this is always a valid heuristic, but it might be valuable to rank projects on the scale of the algorithmic complexity involved in each (which in turn probably depends on how close the project comes to exploring the unknown, as the DARPA race efforts do), and then by how compelling they are and see if there is a correlation. In my experience, while enterprise projects have their own set of problems to be solved, they are rarely algorithmic in nature (vs economic or scheduling issues for e.g). Another supporting factor might be to see if interviews for the interesting dev jobs focus heavily on testing algorithmic knowledge. At first glance this seems to hold as well. If you are interviewing for Google Research, you probably need to be great at algorithms. If you are interviewing for Wipro, not so much - a knowledge of the contemporary buzzwords (agile, xp, tdd, ruby dsl blah) should get you through.