Extreme startup at codecentric

No Comments

Every developer has his own preferred language and software stack, and a lot of religious discussions are held about that topic. So a few weeks ago we decided to find out which is the best/most productive/most elegant stack to bootstrap an application. So Nils Wloka and I invited our fellow codecentric colleagues to play the extreme startup game. In this blog post we’d like to share our experiences with you.

The challenge

Extreme startup is a simple ruby application. After the game leader has started the server, the participants can register themselves by providing a URL (usually their local IP address). The game server then starts to send HTTP requests containing questions to the registered URLs. Players have to implement an application that is capable of answering the questions send by the game server. Every time no response or a wrong result is returned, players get minus points. Correct answers are rewarded by plus points. This is all visualized on a leader board, which we displayed via a beamer at the front of the conference room we were sitting in.

Extreme startup leader board

During the game more and more questions are added, so the players have to extend their application to gather more points. The nice thing about extreme startup is, that it only uses HTTP for interacting with the player, so every one can use the stack of their choice. We were pretty excited to find out which stack would perform best and there where some nice surprises. You can find all implementations on github.

…and the winner is: JavaScript

Ben Ripkens won the race for points with a setup consisting of ECMAScript6, node.js and express.js. He prepared a pretty sophisticated setup using nginx as reversed proxy with at least one instance of his application up and running all the time. Further more he used integration tests to make sure his changes would not introduce bugs into functionality he had already implemented. But in the end he concluded that all the setup has not been the reason for his win. Instead JavaScript’s eval() function made it relatively easy for him to process the questions send by the extreme startup server. You can review the details of his implementation in our github repository.

Closely followed by: Clojure

Ben Ripkens’ JavaScript based stack was closely followed by another dynamically typed language stack. Gerrit Hentschel used Clojure. Clojure’s REPL helped him to test drive new functionally very fast into his application. While being very productive he noticed some problems:

  • Tests executed in REPL are not persistent, which can lead to regressions later on
  • Testing only the handler function of a router can lead to errors in the routing logic itself

In the end he misinterpreted one of the questions, which cost him a lot of points. If it weren’t for that Clojure may even have beaten JavaScript. Gerrit’s implementation can be found in the github repository.

What about Java?

At codecentric we’re doing a lot of our projects with good ol’ Java. That was reflected by three players using a Java 8 + Spring Boot setup. What is to say about Java? Spring Boot really is a game changer when it comes to bootstraping applications. Aside from that it just works. It’s nothing special, not sky rocking but able to compete. The main problem for all Java programmers was Java’s clumsy RegEx and Pattern matching API which made it hard to evaluate equations from a string. Since this is the main challenge in the extreme startup game, languages like JavaScript and Clojure which can evaluate strings just like code have a big advantage here. The Spring Boot application implemented by Henning Treu can be found on github.

The exotic birds

Aside from the usual suspects, we had some really exotic and interesting stuff. Fabian Lange decided to use Java with OSGi and Apache Karaf. Remember OSGi? It’s the framework that promised to solve all our modularity and jar hell problems back in the early 2000’s. For some reason it never really had a breakthrough in business application development. Fabian’s setup included hot swapping new versions of his application after each successful maven build with almost zero downtime. In the end he had the same problems as the user Java guys: It’s hard to operate on strings in Java. Fabian’s setup can be found in our github repository.

Michael Lex decided to go all the way with the type system. His Scala and Akka setup, provided some nice goodies in the long run. Because of lacking experience with Akka, he lost a lot of points in the beginning and though could not compete for the first ranks. Further more very long compile and turn around times hindered him from developing really fast. The good parts of Scala are:

  • A very powerful pattern matching API
  • Testing, both unit tests and integration tests are easy to write
  • Scalas type system: if it compile, it works

Michael’s implementation can also be found on github.

Andreas Houben was the only one who decided for non-JVM stack. He used the extreme startup as an opportunity to learn an new language: Python + flask. Naturally he had to fiddle with a lot of beginners problems (like “how to respond to a GET request”). However, flask was extremely easy to setup and provided him with a fast turn around cycle. Like the Java programmers, Andreas had hard times getting the regular expressions right, which was a bit frustrating for him. So in the end his application wasn’t able to answer all the questions. To defend Python’s honor he replayed the game alone. So you can find his original and his later implementation on github.

What we learned

The extreme startup was great fun for all of us and there are a few take aways we’d like to share with you:

Developers always optimize – Since the extreme startup is all about gathering the most points, all players optimized towards this goal. For example Ben Ripkens used JavaScript’s eval() function, which is considered insecure and bad style. But in this particular situation it was the optimal way to get the most points. Gerrit Hentschel didn’t persist his tests but developed everything in Clojure’s REPL. This was a very good way to be successful in the extreme startup game, but we all know how persistent tests are for long term projects. Further more clean code practices became less important, for example…

Names don’t matter – Under the extreme stress, names don’t matter that much anymore. We hat a lot of test cases like “testFoo1”, “testFoo2”, “testFoo3” and variable names like “bla”. This is because the extreme startup applications are like throw-away prototypes. Since we did not have to maintain the code for a longer than one evening, there was no need to find name that one could understand in a few weeks or even years.

Tests help (surprise!) – Tests helped the competitors on several levels. Since the game server decided when to send which question to which player, there was no easy was to do a manual test. Implementing unit tests helped to develop new functionality very fast, without the need to wait for the game server to send a question. Further more tests helped to make sure existing functionality did not break.

Integrationtests are important – A lot of trouble resulted from errors in the routing logic of the applications. In this regard it was very helpful to create integration tests for the whole application in contrast to unit tests that would only test the answering logic for single questions in separation.

Finally we can only repeat that the Extreme Startup game is really great fun. We can only recommend trying it out with your colleagues: https://github.com/rchatley/extreme_startup

Benedikt Ritter worked as a Software Crafter at codecentric AG in Solingen 2013-2018. His joy for creating reliable software is not limited to coding at work: Benedikt is member of the Apache Software Foundation and Committer for the Apache Commons project.


Your email address will not be published.