52 Bicycles

I am  considering trying to do more of my commenting through trackbacking rather than direct posts. Better for my friends’ google rankings.

In that spirit I raise Dharmesh Shah’s Disagreeing With Paul Graham: How Not To Pick A Platform - which is itself a comment on Paul Graham’s recent essay, 18 Mistakes that Kill Startups. I agree with Dharmesh’s point, which is essentially practically in full:

Paul Graham:   “How do you pick the right platforms? The usual way is to hire good programmers and let them choose. But there is a trick you could use if you’re not a programmer: visit a top computer science department and see what they use in research projects.”  

I agree with the first half.  A great way to pick a platform (if you’re not a programmer yourself) is to hire great programmers (not just good ones) and let them choose.  But, I don’t think visiting a computer science department and seeing what they use in research projects is an effective strategy.  Here are my issues with this particular approach:

1. Being a prior computer science student myself, I have a bit of a feel for how platforms get picked for research projects.  Rarely do these coincide with how startups in the real world work.  People in academic research projects are often solving for a very different problem with very different motivations than a startup.  Lots of research projects are a learning exercise.  Most startups are a building exercise.  The desired outcomes are often vastly different.
2. The platform selection process is sometimes domain and/or user specific.  For example, though Python is a cool language (and I’m sure there are many academics that like it), if you are seeking to build the next big killer desktop application to run on Windows, it will likely prove to be a fatal choice.  The reason is simple.  From a user’s perspective, they expect a Windows application to look and feel like a Windows application.  Chances are, your Python desktop app won’t quite feel “just right” (the user’s dog will bark at it).  This is a case where the users do care about the platform choice because it actually impacts what they experience.  Similar arguments can be made for other target areas like mobile applications.
3. There may be other dependencies (i.e. integration points) that influence your decision.  As a startup, if you are building an application that will be an extension of an existing application (or consume its services somehow), it often helps to pick a platform that is conducive to that integration.  For example, if you’re building an Outlook plug-in, you probably don’t want to use Ruby for that (even though it might support COM). 

   Basically, it seems that Paul thinks that all startups are going after “change the world” strategies and don’t need to concern themselves with user preferences, business domains or the need for integration with existing systems.  Though it would be great if this were true, it’s really not.  

My comment from Dharmesh’s Python post was this:

I am a fan of languages and structures getting out of my (and the way of my associates) way so as to create the most useful tools for our clients. And have found that languages that have the shortest learning curve from what I know now to what I want to do are the ones that wlll be most productive.

Let me try cutting this another way too: picking a platform that is easily accessible by those who are not CS majors improves my ability to put intelligent people who are not CS majors on the project, which changes both the labor economics dynamic and the universe of smart people I can tap to help make extraordinary software.

This entry was posted on Wednesday, October 18th, 2006 at 12:42 pm and is filed under Technology Business. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed. Reddit This