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.
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.
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.
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.
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:
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.
The extreme startup was great fun for all of us and there are a few take aways we’d like to share with you:
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