I’m a little obsessive about the tools I and my co-workers use. If I come into a company and they’re still on svn, I push to get us switched to git. If people have to login to a remote server to develop on via a slow internet connection, I figure out how to get a local VM install to do everything we need, and share it with everyone.
So when my current company started experiencing pains with PHP, and the other devs talked about switching languages, I immediately thought of persuading them to switch to Clojure.
Why Clojure? It’s fast. It’s code is compact but still readable. And it’s got the power of Lisp.
I got permission to build some internal tools in Clojure, and set to work. I thought it was just a matter of time before the other devs would “see the light” and start switching over to Clojure.
Nine months later, we’re still building everything in PHP. No one’s even looked at my Clojure code. Beyond some jokes about Python, there’s been no further movement toward switching languages.
But why? In order to document my mistakes, so I and others can learn from them, here’s what I did wrong:
I’d only been using Clojure for a little over a year when I started building those internal tools. I’d never deployed a Clojure application, didn’t know too much about how to write tests in Clojure, and had only done hobby projects using it.
As a result, those internal tools I built were full of bugs when they launched. When I got pulled off of working on those tools and back to working on the core company applications, those bugs stayed – for months – without being fixed.
My co-workers’ first experience with Clojure was of a buggy, slow application that didn’t do too much. That first impression was hard to shake, even after I went back and fixed bugs and improved the apps.
Not only were the web apps slow and buggy when they first launched, they looked terrible. I got so focused on using Clojure that I ignored the user interface, and didn’t get a front-end developer to help me with it.
Some of the my co-workers were brave enough to use the applications I’d built, despite the bugs and horrible user interface. They all had good feedback, and gave it freely.
I documented everything they told me, capturing it in Jira tickets, and then sat on them for months.
Why? I’d been pulled off of internal tools to doing other application development. So instead of being able to iterate with my users, constantly improving the application, they had to wait a long time before they saw any changes. I lost what goodwill I’d had to start with, because I didn’t respond to their needs.
None of the other developers had any experience with Lisp. But instead of hosting a training session, or calling for a special code review session with Clojure as the topic, I waited for them to “come to me.”
I was certain that some of them would peek at the Clojure code, just to see what it was like, and then start asking questions. I told myself this was the natural, organic way to start spreading Clojure knowledge around the organization.
I was dead wrong. The other developers had a hard enough time deciphering PHP code from 2 years ago; they weren’t going to spend time trying to read my stuff too. Especially since it was buggy. And slow. And hard to use.
In the end, I should have been much more proactive if I wanted to see Clojure adopted at my company. I should have given them some training, carved out some time every week to maintain the applications, and gotten some design input from the very beginning so the tools would be easier to use. Even then, we might not have decided to switch to Clojure, but at least then it would have been an informed decision, based on well-working example applications that everyone was using.