All those cool technologies out there, I wonder how any young developer will have space for them on their two-page curriculum vitae. And it's not just the quantity, it's the names. Languages, operating systems and middleware used to have nice short names and acronyms. Concise, optimised, no more than four characters long. But now we have “Ruby on Rails”.
above. Choose the right tech for the job.
There's a trend here: The longer the name of the technology the more concise the language and the shorter the development time. At least, that seems to be what's proposed by many new technologies.
The emerging languages don’t cut the mustard as far as product development goes. I wouldn’t want to support and evolve a product for the next 20 years and use anything but a well established enterprise-grade platform. But that said, sometimes a cool new technology can satisfy immediate needs for a tactical or short-term solution.
The Register ran a report on Twitter's migration to a new system architecture. Reportedly because Ruby on Rails just couldn't hack it. It scaled up to a point then just fell over, famously during Jobs' keynote at a Mac show. To be fair, a massive burst of traffic can bring almost any system down with the right set of conditions. However, Twitter recognised that there was a general scalability issue here, and Ruby was not going to allow their platform to scale along with their business ambitions. So, on the server side, they've swapped Ruby for a little known, concise, language with no proven enterprise track record, called Scala. Okaaaayyy... Let's hope they benchmarked it this time...
Ruby, Scala, Java, ASP.NET, C++ and AMOS Basic all have their place and valid uses. Pick one that’s appropriate for the job, and make sure you prove it can meet your requirements.
above. AMOS Basic – The right architectural choice for bedroom coders in the 1990s.
If you're working on a new OSS system you should quickly narrow the choice based on the fact that there are three categories of technology out there:
Suitable for enterprise-class OSS products. A commercial off-the-shelf (COTS) product's primary non-functional requirements will be portability, scalability, configurability and manageability. Manageability, if it is a real word, means basing the product on technologies that have good support services, release cycles, flexible licensing terms and limited inter-dependencies. You need to be sure your platform components are thoroughly tested on a variety of enterprise servers, and will be supported and maintained for years to come. Broad industry adoption provides some reassurance that the technology will continue to be invested in for the foreseeable future.
Suitable for enterprise-class OSS projects. If you're developing a point-solution, something that has horrendously short delivery timescales and will probably be hacked around every other month, you might as well use any relatively proven technology, whether that be Ruby on Rails or some drag-and-drop Java tool. Rapid development is the priority, provided a stable technology is used, but as its built to a fixed specification and a single known environment the concerns around delivering a managed COTS products are far less relevant. Not every project is led by time-scale. If you're producing something to be used throughout a large service provider that must support network/service evolution then you're effectively writing in-house products.
Other stuff. Some technology is not sufficiently proven to be recommended for anything but the odd proof-of-concept or small tactical intranet application. Other technologies are starting to fall into the gap between enterprise platforms and emerging technology. PHP, for example: Would you start a new project using PHP rather than going with either Java or cool/hip/funky Ruby on Rails? No, PHP is soooo four-years-ago.
Twitter was developed like a small project to deliver a cool little application. I don't think for one minute any product managers sat down to discuss functionality and non-functional requirements. It's just not the romanticised web 2.0 way, is it?
I like new stuff, I really do. But when it comes to using something for an OSS product it better be scalable and robust first. Concise, agile, and rapid would all be on my wish-list, but not near the top. Maybe that's why my CV fits on two pages.
