Are you working with the technology, programming language and tools that you like? Are you having fun working with it?
When a new project starts, the company has to decide what technologies, frameworks and tools will be used to develop it. Most common sense factor to take into consideration is the tool's ability to get the job done. However, especially in Java world, usually there is more than one tool able to pass this test. Well, usually there are tens, if not hundreds of them. So another factors have to be used.
The next important and also quite obvious one is how easy the tool is to use, and how fast can we get the job done with it. "Easy" is subjective, and "fast" depends strongly on the tool itself and the environment it is used in. Like the tool's learning curve or the developers knowledge of it.
While the developers knowledge of the tool usually is taken into account, their desire to work with it (or not), usually is not. Here I would like to convince you that it is really important too.
Known != best
There are cases where it's better to choose cool tools instead of known ones. Yes, the developers need to learn it, and it obviously costs some time, but I believe it is an investment that pays off later. Especially if alternatives are the ones that the devs are experienced with, but don't want to use any more. Probably there are some people who like to code in the same language and use the same frameworks for 10 years, but I don't know many of them. Most of the coders I know like to learn new languages, use new frameworks, tools and libs. Sadly, some of them can't do it because of corporate policies, customer's requirements or other restrictions.
Why do I believe such an investment pays off? If you think developer writes 800 LOC/day, so 100 LOC/hour, so 10 LOC/minute... well, you're wrong. Developers are not machines working with constant speed 9 to 5. Sometimes we are "in the zone", coding like crazy (let's leave the code quality aside), sometimes we are creative, working with pen and paper, inventing clever solutions, algorithms etc. and sometimes we are just bored, forcing ourselves to put 15th form on the page or write boilerplate code.
The power of fun
Now ask yourself, in which situation you (or your developers) usually find themselves? And if you are often bored, working 5th year with the same technology and tools, think about the times when you were learning it. Remember when you were using it for the first time? Were you bored then? Or rather excited? Were you less productive? That's truism, but we are not productive when we need to force ourselves to work. Maybe it's a good idea to change your work to be more fun? Use some tools you don't know (yet), but really want to try? It might seem you are going to be less productive, at least at the beginning, but is it really true? Moreover, if it allows you to write less boilerplate code or closures or anything else that can make you faster and more efficient in the long run, it seems a really good investment.
There is one more advantage of cool and fun tools. If you are a company owner, do you want your business partners to consider your company expensive but very good, delivering high quality services and worth the price, or not-so-good but cheap? I don't know any software company that wants the latter. We all want to be good - and earn more, but well deserved, money. Now think about good and best developers - where do they go? Do they choose companies where they have to work with old, boring tools and frameworks? Even when you pay them much, the best devs are not motivated by the money. Probably you know it already. Good devs are the ones that like to learn and discover new stuff. There is no better way to learn new stuff other then working with it. And there are not many things that are as fun for a geek as working with languages, technologies and tools they like.
So, when choosing tools for your next project, take fun factor into account. Or even better - let the developers make the choice.
--
This presentation might be interesting: http://www.infoq.com/presentations/Scala-Guardian It's Graham Tackley story about how they introduced Scala in Guardian, and what happened then.
Cool image courtesy of Łukasz Żuchowski http://blog.zuchos.com
