Last Saturday we had the first ever Lean Poker Tournament, an event much like a code retreat, but with a slightly different format and purpose. A lean poker tournament's aim is for participants to practice concepts related to lean start ups and continuous deployment. A poker team is a small group of developers (ideally 4 people forming 2 pairs) whose aim is to incrementally build a highly heuristic algorithm within a one day time frame that is just smart enough to beat the other robots. Professional poker robots are developed for years, so the purpose is definitely not to come up with something really smart, but to be the smartest among the current competitors. With this in mind teams can come up with simple to implement heuristics, examine their effect on game play during training rounds, and then improve their algorithm in a similar lean fashion.
This year I have talked at different Hungarian venues about software development related topics several times. Although these presentations are captured on video and are available on the internet they are in Hungarian, so I decided that the next few posts will explore some of them in English, and in more depth.
I gave the Test Driven Mockery talk at the April event of PHP Meetup Budapest. Although code examples and frameworks are in PHP, the talk is basically language agnostic, and it's just as useful for PHP programmers as it is for Java, C#, Ruby or even C++ coders. After all: it's about test doubles in general.
At the time of writing this blog entry more and more software developers and companies decide to adapt test driven development as one of their primary practices to avoid code rot and fear of change. Of course there are crowds who still haven't even tried TDD either because they haven't heard about it, or it sounded too weird for them to try. However there is another lot more interesting group of educated professionals who after practicing TDD for a considerable amount of time decide to abandon it. As I was talking with a group of these people I recognized that most of the time their disappointment in the technique is easily tracked back to their misunderstanding of a very important related topic: test doubles and mocking. On one hand if you completely avoid using them you end up with a slow and fragile test suite that's hard to maintain, but if you use too many of them the promise of ease of change, well tested and flexible code becomes a lie. Finding a good balance is kind of an art.
Yesterday we held our first Legacy Codereatreat in Budapest. While it is very similar in concept to regular Coderetreats, there are some very important differences. We start the day by introducing an existing legacy code base - a rather ugly one - and let the pairs figure out what it does. Yesterday we've been using the trivia code base on GitHub, so that participants could choose from a large variety of languages, but still have approximately the same code base.
According to Michael Feathers' definition of legacy code: "it is code without tests". So after the first getting to know session the next session was about adding characterization tests to the code that would help us during the remaining sessions. Since the only UI to the application are log messages, but they are scattered all around the code base, it is a relatively safe test suit to generate runs with random inputs, and save the output for reference. It won't help in figuring out where the error is, but it will catch most of the mistakes one makes during refactoring. They can also help when adding behaviour, but when fixing bugs they will brake, and need to be replaced.
Last week I have attended a free conference in Budapest themed around web development. Here is a quick recap. Unfortunately the conference was held in Hungarian, so most of the resources I link to are in Hungarian.
János Pásztor described how they built up the infrastructure for a tiny start up called neticle.hu. His talk was recorded on video, and a short lecture note is available. It's a very good starting point, and contains a lot of information on tooling. The most important part for me was where he talked about configuration management: with the right tooling it can become almost automatic to add a new server to your system. Definitely worth a bookmark if you plan to start your own web based service some time in the future.
About 9 month ago as we were preparing for the next Coderetreat Athos came up with an idea for a game he called the changing requirements. I liked the idea from the get go, since I think that in becoming a software developer the hard part is learning how to react to business needs. At least for me that took a lot more time than to write my very first game in QBasic as a little kid. The really sad part is that one can graduate university without ever even realizing that he is missing one of the software craftsmens most important virtues.
What I found really appealing in the concept of Coderetreats was that it provided a forum for professionals to learn about techniques that can help in dealing with change. On the other hand it is about getting away from the pressure of getting it done, and by that it takes these techniques out of context. It's kind of the price for letting you concentrate on practice.
The changing requirements game is something we like to play as the very last session of a Coderetreat. By that time the participants have learned a lot of new things, and have become familiar with game of life. The session is 90 minutes long - enough time for a pair to finish the job - but we come up with requirement changes at times when it's already too late to incorporate that into the design without substantial refactoring. If the pair has already learned how to do evolutionary design they will easily adapt, otherwise they will have quite a bad time. Either way they will hate the facilitator for a second, and then they will get really excited about the problem.
Last week we had our 4th Coderetreat in Budapest with about 15 participants. This time I was an organizer along with Athos, and we decided to advertise the event at several different meetups. While preparing slides for the talks we realized that on one of the slides we had some free space we could not really fill... so we came up with the idea of putting an image macro there. And that's how Uncle Bane was born:
That kind of unleashed an entire flow of crazy meme ideas, so I decided to popularize the Coderetreat event by posting these memes on the groups Facebook page. (Check them here.) The meme that turned out to be the most successful was this one:
This year I've been lucky enough to visit NDC (Norwegian Developer Conference) as a crew member. Fortunately we didn't have to work much, and even when we did, we were in the lecture rooms listening to smart people. So here are my thoughts on what I heard during that 3 days in Oslo, and a few videos from the talks I found most useful.
On Thursday I was talking about Uncle Bob Martins book, "The Clean Coder" on a meetup organized by Agile Hungary. The talk was in Hungarian, but it's already available on YouTube (not embeddable, so please follow the link), along with the slides on SlideShare:
Yesterday I was participating in the Budapest event of Global Day of Coderetreat. It was a very intensive day of coding in pairs. The basic idea is that the same programming task - specifically the implementation of Conway's Game of Life - is repeated in six 45 minute sessions. Since the pairs were switched after every other session, and people came from different backgrounds, this was a great opportunity to learn from each other. Also one could try different design decisions, and see what are the benefits and liabilities of each.
For me this was the first time I did real pair coding, and the most important experience of the day for me was that pair coding is good, good, GOOD. 🙂 Even better for me was when we were doing TDD ping-pong with Athos.