Admittedly, I was mildly shocked and a bit scared when stumbling over @ZackMaril’s recent tweet claiming Clojure was a dying language. A huge discussion was sparked and a lot has been written since. A summary can be found in Arne Brasseur’s post which also offers some good insight into the community behind Clojure. Eric Normand added another layer of abstraction today and collected some more links in this week’s Drama edition of the newsletter.

I share Dan Lebrero’s sentiment on Clojure. Clojure taught me lessons and introduced concepts to me  that I do not want to miss any more. First and foremost I love the built-in immutable collections. Immutability as default is a milestone in my life as a developer. I compare it to git, pair-programming, continuous integration and IntelliJ IDEA (with Cursive now, of course). There was a time when I did not even know about each of these. Now I cannot imagine to ever work without any of them.

In this post I want to emphasize another not less important aspect: Productivity. With Clojure we get a whole lot of stuff done. Seriously.

A little more than a year ago, things at work were completely different for me than they are now. I was a Java programmer working on a big, monolithic piece of software. There was also some JavaScript for frontend and MongoDB, some Groovy for scripting Gradle and the occasional Bash script, but if you had called me a 100% Java programmer, I would not have objected. Don’t get me wrong, I enjoyed my job and I always loved to work with Java but as you may relate to, after years of hacking Java, I was a little tired of it. As you may also relate to, I had little hope for the situation to change significantly anytime soon. As it turned out, I was wrong about that. Hugely wrong.

Recently we released tesla-microservice to github. It is a software written in clojure and it is the basis of some of the microservices we are working on as part of the technical platform of We named our software after Nikola Tesla an ingenious engineer and inventor of the late 19th and early 20th century.

tesla-microservice is based on the component library, an elegant and quite minimal framework to build stateful applications in clojure.

Currently tesla-microservice allows you to build a basic web application with some basic features:

  • Load config from classpath and/or filesystem.
  • Aggregate a status based on the status of the different components and their subcomponents.
  • Deliver status details as json.
  • Serve a simple healthcheck based on that status.
  • Report to graphite using the metrics library.
  • Manage routes using compojure.
  • Serve content with an embedded jetty.

This is part two of my roundup of  EuroClojure 2014. If you missed the first part, find it here.

Day two started with the keynote by David Nolen about Invention, Innovation & ClojureScript. After some interesting discussion on the difference between invention and innovation, he talked about the history of clojurescript, a clojure implementation that does not target the jvm but javascript as a runtime environment. It was released 3 years ago and since then undergoes constant innovation. To date, the innovations come from 81 different contributors. Examples for contributed innovations are persistent immutable datastructures and source maps, which are very useful for debugging clojurescript. David introduced the basics on react.js and then of om. Om is a clojurescript library on top of react.js. It adds a key ingredient to react: Immutability. By having an immutable global application state, communication between components becomes feasible without any of those crazy interactions, that make classical user interface development so hard. As an example David  showed Goya, a pixel editor for the browser. Due to clojurescript’s persistent datastructures it features undo/redo of a virtually unlimited number of steps with little to no performance impact at all. David finished with an outlook on clojurescript 1.0. Among the goals is better code sharing between clojure and clojurescript.

view from the conference center
The beautiful view from the conference centre.

Last week I attended the EuroClojure conference 2014. It was a truly fantastic conference in the beautiful city of Kraków. While the big conferences in the US attract thousands of participants, this one was rather cosy with some 300 participants. As a very good side effect of this, the conference was single tracked. So I missed none of the great talks.

If you do not know clojure by now, let me start with a very short primer: Clojure is a modern, functional programming language targeting the java virtual machine. It is a lisp dialect, designed for concurrency, performance and code that is easy to understand and thus easy to reason about. One of the most outstanding features of clojure is its immutable, persistent datastructures directly built into the language. With clojurescript there also exists a version of clojure targeting javascript rather than the jvm as a runtime.

Fast feedback is a cornerstone of agile software development. When developing the LHOTSE project at Otto, we tried to be as agile as possible and many of our means and methods revolve around fast feedback. Here is a list of my favourite things we do to foster fast feedback. It does not at all cover everything we do in our daily work, let alone everything one possibly could do.

All methods have one thing in common: They try to let the development team know as early as possible when things are going into the wrong direction. The key hypothesis is: The sooner you recognize a mistake, the easier it is to fix it. If you introduce a bug in the software, it is easiest to fix it right away, when you still know what you where doing and when you can associate the bug with the small change you just did. When you learn about a bug later, you first have to identify the change that introduced it, then try to remember the intentions of that change. When adjusting the change, you have to be careful not to break anything that was built on top of it later.

The term Commitment was removed from The Scrum Guide (pdf) and replaced by the term Forecast back in 2011. Here is my rant against the concept of commitment as it is still used by many otherwise agile teams. If you don’t do scrum, but any other development method that ties a fixed set of development tasks to an iteration, then this article is also for you. You must not mistake ceremonial commitment with the commitment of individuals and teams to deliver excellent work. We all agree the latter is a great and desirable thing. In this article I am only talking about the former.

Sprint commitment means, that a team of software developers have to commit to finishing a fixed number of stories in the next iteration. I guess the hope often is, that due to the pressure created by such a commitment more stories are developed per time unit. I also heard the reasoning commitment would improve planability of a development project or that it increases the motivation of developers. I think that is all wrong.