New library or language? A checklist

Note: This blog is an unfinished form, written late 2016, but rather than write an epic, I thought it would be good to share some of the thoughts here.

A colleague recently suggested we use Project Lombok with our Java code. The company I work for also has some experience with Kotlin. We’re a new team, I could see pros and cons for each. ¬†In a world where Java 8 has been widely adopted, alternate JVM languages don’t get the free lunch that they used to when it comes¬†to simply reducing boilerplate and introducing closures as a way to¬†get developer mindshare.

Picking libraries¬†and frameworks is something we do frequently as technologists. I thought I’d document the mental checklist I went through when Lombok was recently mentioned. The¬†criteria will vary based on your own experience and your feeling on how it will be adopted in your team.

There feels like there is a swing back to native Java over languages. I know of in Melbourne at least, of a few companies¬†that have experimented in another JVM language or two, but¬†are now building code back in Java again because it is easier to get talent, and the¬†domain is now well understood that re-writing and maintaining in Java 8¬†won’t leave the project lacking.

On a completely new project & new company, the experience, tooling, and team process is all up for grabs. ¬†Most recently, as Java has made strides again in its development,¬†and those who have experimented with other JVM languages and found hiring for that talent more difficult. I’ll spend the rest of this blog looking at Project Lombok, and a checklist I thought about in evaluating it.

Continue reading “New library or language? A checklist”