Berlin Clock Code Kata

Introduction

We recently had our first RES Code Kata, where Software Developers, Analysts, Data Scientists and Power Plant Optimisers all got together to practice coding. We were spread across 5 locations and 3 countries.

In our day jobs, we are often in a bit of a rush, and tend to do the same things. This makes us good at doing those same things, in the way that we always do them, but does not make us better at different things, or at doing the same things in a different way.

During the Kata we were aiming to do some Deliberate Practice. This involves trying something that you can’t quite do yet, but that isn’t too much of a stretch. It takes more time and effort, but you learn and adapt. The key is to “do less, but with more awareness”, or “rush less and concentrate, in order to maximise learning”, or whatever your favourite similar meme is.

So during the Kata we tried to extend our boundaries. We all programmed in pairs and used TDD, which already takes most / all of us out of our comfort zone. The Berlin Clock Problem we were solving is quite simple, so some pairs also chose a constraint.

The plan was to learn some things during the Kata, but also to learn the method of deliberate practice, so that we can continously improve when return to our normal lives.

Happily, everybody had a good time (which is important), and found it useful

Interesting things

The problem was fairly small, so Object Oriented approaches generally seemed to be more difficult, take longer and contain more code, for no benefit. There probably would be a benefit later if the code was required to support a variety of similar clocks, but its best to do this when the situation occurs, as noted in the RES Cost Effective Coding Guidelines.

The fact that OO approaches were more difficult made some constraints that required it especially hard, particularly “Analysis OOP Style First” and “No naked primitives”.

There was quite a big range in the size of solutions (30–135 lines of code, 30–85 lines of tests). Lines of code is a very crude metric, more lines can definitely be better if they help to make the code clearer, curly bracket languages accept entire programs on a single line, and you could obviously just write no tests. However, all other things being equal, less code is better.

Some solutions communicated their intent more than others. This is a fuzzy concept, but you can get a feel for it by imagining that you don’t know what problem the code is trying to solve, and then trying to work it out from the code and the tests. Using names such as five_hour_row instead of first_row helps here.

Some pairs applied TDD more strictly than others (although nobody went as far as using the Devils Advocate technique). This often takes a bit longer in the time frame of the Kata, but is made easier with parameterised tests and property based testing.

Most pairs tested what could be considered the internals of the solution (maybe third_row(56) ...). This caused problems when refactoring later on, as the tests were tightly coupled to the implementation. Only testing things through the public interface (and keeping the public interface small) helps here (so maybe berlin_clock('12:56:01')[2] ...)

There was some discussion about how to write code without using any conditionals. Indexing in to an array (that could contain functions) definitely works, and there is a FizzBuzz example on Rosetta Code (scroll down to the “Without conditionals” bit). There are also some ways to do it in functional programming languages. This FizzBuzz example in Haskell is good, if a more taxing read.

Solutions

These are the solutions that we created during the Kata. You can see many more on GitHub

Python 1 (Used solution seeker constraint, resulting in a concept of Unary strings, tried not to use conditionals, but did once to check the validity of a parameter)

Python 2 (Used parameterised tests)

Python 3 (Started converting the code to a class structure after initial function based solution)

Python 4 (Only used one level of indentation per method, didn’t use the else keyword)

Python 5 (Used arrays of characters, instead of strings)

C# (Tried Analysis OOP Style First constraint, but found it unsuitable for the problem)

F# (Mostly adhered to functional calisthenics)

Conclusion

Code Katas are a fun and engaging way to share and gain knowledge across a wide range of backgrounds. They are inexpensive to run and can be attended remotely without major issues. Some valuable learning occurs on the day, and ongoing learning continues after the event with the application of deliberate practice.