Okay, here’s the scenario - your boss has a new project for you: A Web 2.0 Social Media Ajax Web Application for Managing Baby Pictures. So, as everyone starts writing out requirements and figuring out advertising deals with Gerber, it’s your job to decide what technologies you are going to be using.
Ruby? Perl? Java, PHP, Python, Cold Fusion, .Net …
Rails, Struts, Spring, EJB3, Zope, Hinabe…
Apache, JBoss, Lighttpd …
Linux, Windows, Solaris
Oracle, MySQL …
Why didn’t I go to med school?
There are enough technologies and platforms out there that something as simple as building a website can lead to huge amounts of analysis paralysis. But the risk here is huge - if you choose poorly, the site won’t scale, everyone will be fighting the system trying to get new functionality in place, you will be hated, the company will fail and you will end up living in a box by the river in six months.
Or maybe not.
So what’s the right technology to implement your new project? The answer is actually very simple - it doesn’t matter.
No, seriously, it doesn’t matter.
No software project has ever succeeded or failed because someone chose Cobol over Ruby on Rails. Projects succeed or fail based off of three things:
1. Having “the secret sauce.” (which means your baby picture idea is going to fail in every language)
2. How quickly you can get the sauce in front of customers.
3. How well you can get the sauce in front of the right customers.
Its not about programming languages, scalability, open source or anything else. They will matter later, if you are lucky, but none of those things matter RIGHT NOW. So what technology do you chose?
Chose what’s in front of you. Your team knows Java? Then write the damned thing in Java, regardless of what 37signals.com is telling you. You like Ruby? Write it in Ruby and ignore the “it won’t scale” arguments. Are you poor? Use the LAMP stack.
But what happens when we get big? What happens if we could have written it faster in some other language? What happens…
Skip what ifs, because face it, the odds are against you. There is no framework out there that let’s you automate the build of eBay. PHP doesn’t have a <facebook> tag. If what you are trying to do is good and valuable and unique, then no one else has written it before, and you’ll need to implement it no matter what.
So when it’s all said and done, if you are lucky, you’ll end up with a few things:
1. A system you are reasonably familiar with.
2. A customer base that’s growing faster than you expected or planned for.
3. A whole mess of things you wish you’d done differently (functionality you wish you hadn’t wasted time on, poorly designed algorithms, a lack of a proper test harness)
Again, this is a very very good thing. Yes, it would have been easier to write a test harness and full set of unit tests earlier. Yes, you should have planned for load better. Yes, you really wish your code had better documentation so the new guys you hired could get up to speed faster. But you have customers, and hopefully that means you have revenue, which means you have a much better chance of surviving than if you had a scalable system with a great test harness but no revenue. Never ever worry about something until you absolutely positively have to.
This sounds like the advice given to a startup, but its true for projects in large companies too. Unless you have some brilliant political connections, or at least pictures of your CEO doing things in Vegas that should have stayed in Vegas, then you are going to be beholden to the same revenue trap as the startup down the street.
Of course, that leaves one big ugly open question: if I do everything right, I’m going to have to start worrying about everything I did wrong at some point. When do I know what that point is?
But I’ll save the answer to that for another day.