jscr3peopleFirst and foremost I would love to thank all the attendees that made the #jscr #4 such a cool event, which obviously made it worth spending another Saturday on working on our coding skills. And of course I would love to thank Martin Ruprecht who facilitated the event with me and Irene who has put in lots of the work behind the scenes. E.g. the good on-site made pizza was just one of her ideas and that was a great lunch, just like last time.

Five times 45 minutes

For those who don’t know the event here comes a short summary of what we did.
Upon arrival everyone could have a coffee, brez’n, Club Mate or whatever other refreshment/breakfast (s)he needed to get over the early start, 9:30 on a Saturday morning.

After a quick introduction of how the day will be structured we started right away with the first session. All the sessions every attendee chose a new partner to work in pairs all the time. Of those sessions we had five, each lasted 45 minutes, which I think was enough to get everyone exhausted. In all sessions we tried to solve one problem Conway’s Game Of Life (GoL). GoL is perfect for such events, it is not too simple to get bored and not that hard that the solution is impossible.

Session 1: Everyone started out by solving the problem in a test-driven manner. It was meant to get familiar with the problem, everyone to wake up and get into gear. The mix of groups seemed to have been perfect. Everyone had understood the rules of Game of Life and the problem of the day needed no more explanation. (Was is the Club Mate?)
Session 2: We increased the difficulty level a bit, we did a ping-pong session. Ping-pong here means to pass the keyboard forth and back between the pairs. You write a test that fails, pass on the keyboard. Your pair writes the according production code and a new failing test that has the intention to move your production code forward. And you pass the keyboard back. If you wanted to increase difficulty you could set a timer and not allow more than three minutes to pass until the production code makes the failing test pass. If you didn’t succeed remove the written code, since it seems to be too complex and a simpler test should be chosen, refactoring be applied first or another solution be found that allows you to get it done in three minutes.
Session 3: was the one I was really looking forward to, we called it “Create legacy” the idea is by Marc Bless who described it here. Fortunately nobody had done it before and that made it most fun I guess. The task was GoL again but quick+dirty this time. After 15min we took one person out of every team, told them to put on the Clean Code hat and go back to another team and push for clean code, tests, etc. You can’t get much closer to real life I guess :).

Then we had a great lunch, from the pizza truck (really worth it!).

Session 4: Probably the most extravagant one. Everyone had to implement GoL in Google Spreadsheets. I showed the basics on how to do TDD and JS in a spreadsheet. Lots of awesome ideas and for the first time visuals came out of this session. More about that later.
TDDbin in actionSession 5: The restriction was not to use a mouse. Since most people used TDDbin.com we enhanced it a bit and people could also choose another no-restriction, we offered: No IFs and no more than four lines per function. Some people even combined them.

After each session we had a (sometimes) short retrospective to share our experiences and also to laugh a lot about the crazy things that one might comes up with when applying those restrictions. All the way at the end we had some beers and some of us even stayed and chatted until almost midnight. All in all a beautiful day, thanks a lot! We will repeat it, for sure. Or feel free to join us and do the same thing in your city. Or invite us to do it in your city.

Creating legacy session

Just a couple days before this event I was surfing through coderetreat.org in order to see if there are some interesting restrictions that we could copy for this event. And out came the “Create legacy” restriction by Marc Bless. Already when running the session we realized that we need to improve our execution of it. But first things first. The introduction for this session was quite short. We said “build the GoL as fast as you can, in a quick and dirty manner, no TDD, no clean code, etc.”. I think everyone was a little surprised by that. But everyone started straight away. We tried to stress everyone a little bit by making manager-style comments to push the code size and the number of features. I don’t know if it worked. At 15 minutes in we told everyone to quickly pay attention. We told them that one of each pair will have to leave the team and please come to the back of the room. There we told them that they are now the seniors that only accept clean code, tests and quality, no bullshit and no hacks. We sent them back to a different pair, so they don’t work on their own code anymore but on someone else’s code.

In the end some teams really removed most of the old code and rewrote things. Some didn’t know how to test the legacy that had been created before. Others reported that all those 45 minutes were basically wasted because the old code didn’t work and only in the end they found out that it all needs a rewrite. Some people also reported that this very much feels like the real day-to-day work. I just couldn’t resist to mention that everyone only had 15 minutes to create legacy and already that was hard to work with. Just imagine legacy code of two years of age.

Our learnings from the “Create legacy” session

We realized quickly that we can improve the execution of this session. We did it for the first time, so Martin and me quickly agreed that this is a really cool session but we know the edges that it has, or at least that we added to it.

  1. Stricter instructions – Already when all the teams had started we realized that our instructions could have been better. Something like “you have 15 minutes to create GoL, get at least all the rules done in 15 minutes.” Would have been better. Since we didn’t explicitly mention that there will be an interruption at any time I think people didn’t feel the pressure soon enough. We kept the coming interruption a secret. I think this makes no sense.
  2. Just have one coder – Another option that maybe makes this even harder could be to tell the teams that only one person shall be writing the code. And when we interrupt the teams we take this person out of the team. This will add the additional effort which might cause “all the knowledge to be removed” from the team. In the best case the team has really paired well and both understood the code well, then the coming cleaning part will be easier. But in case that the passive pair also has problems understanding some of the code the discussion and maybe even confusion would be much more fun.
  3. Only let the clean-coder code – When the clean coder joins the team she should take over the keyboard. This will ensure that the old code gets touched and the “legacy owner” will have to explain and reason about the current code. This might trigger more discussion and hopefully also engages both parties even deeper. And it prevents the situation that the legacy owner doesn’t give up control.

Lot’s of room to improve. Anyway this was one of my favorite sessions this day and I will make sure that it improves.

GoL in Google Spreadsheets

Why Google Spreadsheets? All got started by the past experience with it. And spreadsheets offer a couple of nice features. One is the input can be created in a very simple way. Just two numbers, each number in a cell. Or even just one number. If you want to make it more complicated you can. A second feature that I was really looking forward to seeing was that a google spreadsheet is nothing less but a grid, which is also part of the GoL. Maybe someone will come up with a solution really rendering it in the cells. And there have been solutions like that. The other feature of a spreadsheet is that you don’t need no test framework that is in your way sometimes. The specification can be easily readable and maybe even manager-compatible. But we didn’t get that far.

I had made some good experiences using Google Spreadsheets for introducing TDD to students. The simple red-green visualization was also one of the features people brought up during the retrospective at this retreat.

Others realized that input can and maybe should be simplified in order to make it useable in such a minimal environment that spreadsheets just are. This approach also made it very tempting to not focus on one test at a time, since it was able to just create many tests at once.

The simplicity of test creation was another learning that came out of this session. Which means in spreadsheet duplicating and adding more rows is pretty simple, once everything is set up. Using this you get more time to focus on the coding part and the building of tests actually boils down to an initial discussion and agreement among pairs and in an ideal case it is no topic later on, which means you get a maximum of time to make your code better. Which also bears the danger of not discussing tests too.

The community

Again I have to say it was really great to see the people engaging a lot during the event. And all that on a Saturday. When you hear the people talk about small tests, units, restrictions and GoL internals during lunch you know they are hooked.

Let’s do it again! And we will, just watch out for #jscr #4 in December.

Happy hacking…