Recently I ran a session on Object Calisthenics. I was first exposed to this challenge a few years ago and personally found it a fun, yet difficult experience. This is intentional as the challenge is designed to push the boundaries of best practices. The instructions are simple, there are nine rules to follow that must be obeyed during a traditional kata. We chose the Checkout Kata as the backdrop for this session. The teams feedback is as follows.

Use only one level of indentation per method

The team found this easy, and we discussed that following this to some degree in day to day development would be beneficial. Limiting the amount of nested code you have can improve readability quite substantially.

Don’t use the else keyword

At first this seemed a no brainier, until people realised it meant to favour polymorphism and not simply relying on an early return (implicit else).

Wrap all primitives and strings

The team managed well with this, one example would be a pair introduced an SKU (Stock Keeping Unit) to encapsulate a string and price. We do this well in day to day development at Codeweavers for domain objects, however we tend to fail in other areas such as data access code. This is one concept we need to try and improve at.

Use only one dot per line

The Law of Demeter in action. Once we cleared up the ideas behind this it was pretty easy for the teams to follow. This is not a dot counting exercise, so it is worth being familiar with the “law”. Much of our code would satisfy this requirement.

Don’t abbreviate

One controversial point that came up from this was regarding the team who chose SKU as a class name. Some of the team disagreed with this naming, though in terms of the domain (a supermarket) this is a perfectly valid name, therefore this did not break the rule. On the whole our code is named well, though our legacy codebases have many abbreviations that can confuse and obfuscate the intent of the code.

Keep all entities small

For new code, this is not an issue, however we find legacy code is given less treatment in regards to the size of our entities. This is something we should try to improve, though the teams found this easy enough during the kata.

Don’t use any classes with more than two instance variables

Personally I find this an odd requirement, providing you keep your classes small as per the previous requirement this tends to be a less relevant task. Of all the rules to follow, this is the one I could not advocate during day to day development providing you keep your classes small.

Use first-class collections

My personal favourite of the rules to abide by, and one I have since adopted into day to day coding. First class collections can simplify, and make code easier to understand as well as maintain and optimize. We have numerous examples of this at play at Codeweavers, and we should try to increase the amount of custom collections we have, as opposed to relying on primitive collections. For example, quotes is a better object than a array of quote.

Don’t use any getters/setters/properties

The hardest of all the rules to follow. Most of the teams tried to get past this rule by simply naming their getters/setters slightly differently. At the end of the day, there were still exposing state unnecessarily. We would never try to enforce such a rule for general development, but for core business logic this principle actually makes sense. The areas where this falls down, is on the boundary of the system, for example user input or output would be such scenarios where getters/setters are the easiest, cleanest solutions. Each team found this requirement the hardest to work with, which mimics my first expose to the object calisthenics challenge.

Last week we had @kevinrutherford in to run a coderetreat. It was the first retreat I’ve taken part in personally, the same applying to much of the team. The day was to focus on one challenge – Conway’s Game of Life, though each iteration would introduce new constraints.

Iteration 1

The four rules of simple code were discussed, aka “Extreme Normal Form”.

1. Passes tests
2. Communicates intent
3. No duplication
4. Nothing unncessary

Our first run through was somewhat of a disaster. We became too obsessed with how the grid was to be stored. This meant we spent a long time messing around with arrays and multidemionsal arrays in C#. Both are somewhat tedious and not something we use often, therefore we concluded a more “grid agnostic” approach would be needed. After all, there is nothing stating the grid need be a square, fixed layout.

Iteration 2

The concept of Arrange, Act, Assert or AAA was discussed.

• Arrange – set up pre conditions
• Act – do something on the subject under test
• Assert – verify or check some result

The constraint during this iteration was that all asserts were to be created first, and we would work backwards. Personally I found this difficult, both mentally and in terms of tooling. For the past four years I’ve rarely wrote an assert first, therefore this switch proved tricky.

Visual Studio and Resharper also tend to favour a top down approach. In other words, it’s easier to stub out a class and add methods, rather than the inverse.

New members to the team found the act of writing the assert first much easier however, and they’re looking to continue this in day to day development.

The point I took from here is that while I may personally know what I’m writing, my partner might not be aware of where we are heading. Starting with the assert first allows both developers to see the goal for that particular test.

Iteration 3

Our third iteration introduced the unrealistic concept of mute pairing. Only the code and tests can reveal our intent.

Using ping ponging (switching between developers who writes tests/production code) we managed to get a good chunk of functionality complete. Despite this the rest of the iteration was very difficult. Being unable to talk about design concepts was incredibly frustrating.

The most important concept we took away from here was that more than likely the developer working with your code tomorrow will not have worked with you previously. That means any conversations you’ve had to explain the code will be lost. The only thing left to communicate will be your tests or production code. Due to this observation, it is cruicly we name our tests and code in a manner that is cleary and understandable, whether six minutes or six months have passed.

Iteration 4

Our fourth iteration had a focus on OO concepts. Up until now, our code had exposed much of the state in various ways. The challenge was to focus on the messages that are exchanged between objects, rather the change in state.

This introduced a new problem. How do we test an object without exposing state? We talked about a couple of methods; mock objects or the self shunt pattern.

Using the shelf shunt pattern was an enjoyable experience – we identified numerous violations of the interface segregation principle as it was actually painful to add to the interface in question. With mocking frameworks this pain is often lessened due to the dynamic and often “magic” constructs they employ.

Personally I found code writting using this pattern easier to understand. The plan will be to adopt this approach for a month or so and see how it effects day to day development.

Our code looked pretty good at this point, though we were struggling to replace a conditional statement. After a few minutes the idea seemed obvious once we recieved a hint – polymorphism. This sparked a nice discussion about the “Anti If” campaign – another point I’m looking to take further. This iteration proved the most challenging for the whole team. A second run through allowed further progress.

Iteration 5

The final round had us regroup with our original partners. Here we could use any approach and see how far we could progress. Me and my partner opted for a failing acceptance test, from here we would implement the functionality top down until we had the components wired together. This worked well until we struggled to test how the cells were stored without exposing any state needlessly. The solution came from some discussion around object calesethenics – first class collections.

One thing to note was how drastically different our code looked, when compared to the first iteration. During the course of the day we all noticed a difference in our overall approaches.

Conclusion

Overall I believe I speak for the whole team when I say how much we enjoyed the day. It was refreshing to spend a whole day coding, rather than being interuppted with other issues. Naturally this was quite tiring – though left lots energy for discussion afterwards. As a conclusion it would appear that as a collective we need to spend more time each week carrying out deliberate practice. For new starters this is essential training, while for more seasoned developers this is a useful way to keep our skillset up to date.

After some discussion about bringing back “Google Time” personal projects we decided to try more specific dojo ideas rather than one general kata for the whole group. For our Dojo time today we decided on an open space style session where developers suggested topics and locations (well, which desk they’d be sitting at) that they wanted to try out or investigate. Using the open space style of writing session titles on post-it notes on the whiteboard meant that people could pair up and work on something, try a new technology out on their own, or join a group working on something of interest to them.

Topics today were varied and covered business problems, new technologies and learning experiences:

• Investigating WCF – working on a simple WCF example so that we can explore different configurations and techniques
• Replacing “The God Mock” – this mock that replaced “the God Proc” (which loaded all information for a finance proposal) was quicker than hitting the database for the tests but still very slow as it mocked a 1000 row data reader. Work to speed up this mock by only adding rows that were needed by each test added business value and reduced test times.
• KindleDrop – an app built by Ronnie so that he can test out his test driven development and object oriented architecture skills on this own application
• Codeweavers Support Documentation CMS – our support wiki is getting difficult to navigate and is a problem to rebrand. With new Codeweavers branding in the pipeline coupled with loads of exciting new, customer facing features coming soon we’ll need a support documentation system to cope. After trying lots of CMS apps we’ve settled on Drupal using SQLite – today’s session experimented with WYSIWYG editors, syntax highlighters and menu bars.
• Linked in and Facebook – expect an announcement here (or on Twitter) as we are working on expanding our social media profile to aid communication with our customers
• Build scripts – there always seems to be a way to improve build scripts, even when we think we have them perfectly made. The benefits are far reaching as increases in speed, automation and feedback mean that daily development just flows much faster with a lot less frustration.
• Test Driven Javascript – one of our weak test coverage areas at the moment is in javascript. We’ve dabbled in JSUnit and had a brief foray with QUnit but need something more substantial and permanent. With the release of Jetbrains’ WebStorm 2.0 we thought JS Test Driver might give us a solution that was more like our development flow in C#. We’re experimenting with jsautotest, integrating the server into the IDE and using different framework adapters at the moment with a view to making this a “pit of success” for test driven javascript.

Last week’s dojo was aimed at improving our NHibernate knowledge, this included fresh learning for a number of our latest team members who have rarely touched it and a refresher course for the rest. We use classic NHibernate in a number of our older applications (Fluent NHibernate in one of our latest) and we frequently comment on how our NHibernate knowledge is not as good as we would like. When we have had issues in the past we tend to do some basic research to help get it working but sometimes do not fully understand what went wrong to cause the issue and how exactly what we did to fixed or why it fixed it.

A couple of members of the team spent some time preparing a basic example application and database; it had the basic mappings created with no relationships set-up and one test that simply retrieved all records from a table.

Tasks

For the dojo the rest of the team were given a number of tasks to try and complete starting with simply setting up the relationships. No direct instructions were given as to what, if any, tests were required, just to implement the required relationships. The next task was to display the values from the database on a web app that had been started for them as a way to demonstrate the mappings were correct.

Task three was to complete partially implemented admin pages to allow updating of records which would require the cascade setting of the mappings to be correct. The final task was to delete a particular record and ensure that orphaned records were also removed, again ensuring that the cascade setting of the mappings were correct.

Observations

The outcome of the dojo was interesting in how long it took most pairs to complete the initial mapping tasks. This is something many of us have done before but few could remember exactly how to do them, some resorted to Google, some to looking at existing projects. There were a couple of approaches to testing during this dojo, some opted to do more unit testing yet some opted to do fewer, broader tests; interestingly all pairs chose to do some tests however.

Nobody completed the second task but many commented on how enjoyable and educational the dojo was. We feel that we now have a basis for future dojos on NHibernate to help us learn some more advanced features.

Our code dojo last week was on the String Templater performance kata that Corey Haines performed at the Orlando Ruby User’s Group back in 2009. We use this kata quite a bit, most notably for recruitment as it’s simply stepped approach is great for people not used to TDD.

This is also the reason we did this last week as on Monday just gone the Agile Staffordshire March meeting was on basic TDD and we used this kata as the exercise. The mixture of developers at Agile Staffordshire meant that most of the Codeweavers attendees were the more experienced of the group in TDD, and were therefore pairing with those less familiar. It is also a short kata which always raises a few questions so gets you thinking while also letting you get your muscle memory and fingers warmed up.

As always, we split into pairs, chose a machine, started up a new NUnit project and tackled the kata from scratch. We used Corey’s Specs as a guide, usually naming the test fixtures and methods in a similar manner.

The results were all quite similar. It was noted that in a lot of the solutions we jumped to use a Dictionary object rather than a regular expression, or, as we concluded would have been preferable, a Context object. We’re not sure if this was because we were taking the simplest step to green and not refactoring into a simple object, or because we’d used a similar implementation when previously doing this kata and therefore not spending as much time thinking about the best solution. I expect we’ll just to have to try it again and see what happens. One opinion was that it may be down to our choice of C# – the Ruby implementation seems to favour a regular expression but we seem to like strongly typed objects instead.