Software developer blog

Legacy Coderetreat

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.

Legacy coderetreaters at Emarsys Technologies Ltd., Budapest

Legacy coderetreaters at Emarsys Technologies Ltd., Budapest

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.

@ //

Changing requirements

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.