Experimenting on new projects is not productive

Last update: July 10th 2013

Everyone wants to use new technologies, it's fun and exciting. But it can be counter-productive.

The article hasn't been updated for a long time. If it's code, it probably don't work anymore. My opinions may have also changed, as well as my experience.

I've build a lot of softwares. I don't mean small apps used by 3 people. And as any passionate developer, I want to experiment with new technologies. However this is not wise, issues will probably arise quickly and extra work will be needed to fix everything. That's basically what are saying Marco Arment (Instapaper/Tumblr) and Pinterest.

Where do experimentation fit then?

Experimenting is vital for innovation

Marco uses MySQL over and over again. Is this the most reliable database there is now? Can't you get a free, mature database which is faster, more scalable and has more features?

You need to experiment to build experience and widen you horizon. Focusing on one technology all your life is narrowing your world and if it dies, you'll have no experience with something else and you'll not find any new job.

If it's a tool in your workflow like migrating from Subversion to Git, you don't need to worry about your product or project. But it shouldn't make you slower. By doing so you may have adopted GitHub in the early days. Both git and GitHub made me more productive, GitHub has been connecting me with great developers which is priceless.

On the other side if you change your main programming language, you have to be sure it will not affect your work in any way. I've migrated from PHP to Ruby and Rails because I saw the gain in productivity I will have. It was not reliable enough compared to PHP but I've begun on side projects and after being sure it was mature enough to use it for clients and big products, I fully transitioned to Rails (it was 1.2.6 version at that time).

Your main clients and products needs stability

However I've created some of my products on new technologies that was not mature enough. I've used MongoDB at the beginning of the 1.x version. At that time it was hard to know how to structure your data. It was new and experts or 10gen consultants told us on different blogs and events what were the best practices. Despite that we had a lot of issues and things became unmanageable. If I had more experience with it, I'm sure I would have done it differently.

The first thing you need to think is shipping a great product (or finishing a project on time). On a product you may need to get more performance in a few months (if you're really popular) or a few years if your tools were not enough to maintain stability, performance and productivity. But that's plenty of time to change things.

It's good to try, but don't do it on your main product or a client. Find a side project to make and test it.

Experiment on side projects

Hackathons and Open Source contributions are a great way to experiment with new technologies and softwares. I experimented with Node.js on NodeKnockout (a Hackathon focused on Node.js) and on small side projects before I decided that the performance gain I will have with it will be negligeable for the kind of application I'm making with Rails and that I will be less productive compared to Rails. But I liked my experience with Node.js and if it may fit my needs one day, I will have enough experience with it without risking the life of my product or a project from a client.

In summary, start with familiar tools then experiment new things when you really have a piece that is becoming unmanageable and you need to replace it. Elsewhere, experiment on side projects.