Deleting Code at Nokia Wash Up

I was lucky enough to get the opportunity to speak and QCon london this year on Deleting Code @ Nokia. This gave me a chance to vent the frustrations i had built up having used java enterprise tools in my day job for years. The video will be up at some point and i’ll link it when that happens.

At Qcon they’ve introduced a question submission system so people can tap in questions through out the talk, the idea being that at the end the speaker can review and answer them. I, however, spoke right up to the wire and was so happy to be done I flubbed the opportunity to continue the conversation out side of the room with the question askers, a serious mistake and one i hope to never make again.

So it’s the next day now, i’ve managed to get into the back end of the app to see the questions and created one of these blogamathingys to answer them on.  There’s quite a few (which is ace!) so apologies if some answers are short, feel free to poke for a conversation on any that you feel are too short. So in no particular order here goes:

Have you considered datomic to replace mongodb?

In a word ‘yes’, although i wouldn’t use the word ‘replace’ as really it’s about adding tools to your toolbox or weapons to your war chest, depending on your favoured analogy.  Datomic’s really interesting and comes up in our conversations pretty frequently. What hasn’t happen yet it enough investment in learning and experimentation for us to begin the real adoption push.

How have you found refactoring and maintenance of Clojure across developers for code they didn’t write without static typing and IDE tooling?

I certainly had some reservations in this area and it was a big concern for us. What i think we’ve found is that it’s not as big a problem as feared. The result of having such a small amount of easily understandable focused code is that maintenance isn’t causing us problems. I think a big part of that is our level of acceptance testing, sometimes it’s a little over the top, but too much is better than too little at the end of the day. Refactoring code, if i’m honest, i’m still slow at and it’s something i really want to improve, it’s not caused too much personal irritation yet though, there’s so much less code ergo there’s less refactoring you want to do.

Any challenges regarding transactions when moving from an ejb db stack to clojure and mongodb?

Not as much as you might think. Part of our desire to move away from what we were using in that area was that we didn’t have any complex transactional needs and yet had to pay the cost of tools that provided those abilities. This was one of those realisations that comes out of thinking about what does our software ‘really’ do and whats the minimal tooling we need to get that done.

Was the 71% decrease compared with the beginning ejb or the spring stack?

That comparison was made between an EJB3 service and the clojure rewrite.

Are you saying that unit tests are not necessary if you know for sure what the code does?

Uh, not really. When writing clojure, particularly when repl driving the code, your testing it all the time as you create it. Now you could argue that at the end of that process you could codify the testing you’ve done, but i’ve started to view unit tests as a bit of straight jacket for code, they slow down your ability to change it. What i prefer is acceptance testing, taking the view that i don’t really care how the service goes about doing what i want, just that it does do what i want.

Do you have a legacy of all the technologies you use along the way? How do you deal with that?

There is legacy that gets built up along the way, but there’s an advantage of the small service approach that these things tend not to need much change, after a while they just sit there reliably doing what they do. Of course occasionally you have to go there and that’s when it worth considering a rewrite of the service to a newer style. However you can’t always justify the cost and that’s when you just have to put your professional hat on and do what needs doing. Of course each of those occasions adds weight to the rewrite side of the scales and eventually they’ll tip in your favour.

How did you convince your senior managers to make these changes?

Persuasion. There’s an interesting book about driving technical change from the pragmatic programmers. In brief, you have to relate to their worries and fears, pre-empt them as much as possible, accept the ones that are real and tell them your going to take on the responsibility to see the worries don’t come true and make them believe (in) you. You’ve got to sell it to them basically and selling things to people is a bit of an art.

Did you find any problems/issues when adopting clojure?

Obviously there’s loads that could be said here because issues is a very broad term. Problems, though, we didn’t have many. The big problems are mental ones, your learning a new way to think and persuading other people of the virtue of new ideas, but that’s not so much to do with clojure, those problems exist in any adoption.

Did you find the tooling and the ecosystem around clojure mature enough?

Yes. The ecosystem is vibrant, and full of cheerfully helpful people that are passionate about the language. If i had to choose one thing that really made a big different its Sam Aarons Emacs Live project, this just took a way a lot of the emacs learning required and gave the whole endeavour a huge boost.

how hard was the clojure learning curve for you and junior devs adoption time in terms of keeping a clean and concise codebase?

Hard. It’s not easy, its just simple 😉 Collaboration and communication are key for a successful adoption, sharing your new clojure code with as many people as possible. Something personal that i realised was that with all my efforts to improve my OO code, by breaking things down (i liked the decorator pattern a lot!), keeping my state nicely contained and not mucking about with it too much, all the good things your supposed to do, i was actually laying the ground work for learning a function style. Then when someone showed me clojure it just seemed like a better way to express those ideas; same concepts, far better way of writing them!

How did you train up all your existing Java developers with Clojure? How did you sell this idea to business, given that this would take out many man-days to transition to a new language?

We bought a lot of books and spread them around. Started having the lunch time meet ups and showed it really working for us. A lot of it people self learned in their own time, others used their 20% time to experiment. We didn’t really do any formal like ‘training’, it was mooted and agreed to be a good idea, but in the end it hasn’t happened and the point were it would be useful is passing.

On the man-days point you have to give yourself (and them) a dead line. Essentially saying ‘we think this will work, but if by this point it isn’t, we’ll still have to produce the goods with our current stuff’. You have to earn their trust and make them believe in your ability to pull this thing off.

Has the number of lines of test code increased with the adoption of closure? Have the number of bugs found in production increased?

Not really, we had a strong acceptance testing ideal before, we still do now. The line of test code has decreased massively as there’s very few unit tests and the acceptance tests are really concise. Bugs in production havn’t changed at all.

Why didn’t you liked java in a first place? Why you were trying to substitute it with other language?

In a nut shell i wanted to reduce the amount of time i spent typing out my solution to problems. I want to solve the businesses problems and deliver value, by reducing the amount of pure manual labour involved in expressing solutions is a good thing. Also i started to feel that java was actually hiding the solution to problems, not making them clear. Once you start to see your system as just a flow of data that you apply a few modifications to, you see that java (and objects in general) is not a great tool for expressing that.

Hammered through those a little (late for lunch again!), so apologies if stuff is unclear, but wanted to come back in some way to the people that had taken the trouble to listen to my ramblings in good time.

If you’ve got this far: Thanks for reading!