I attended the Agile Staffs January session on Thursday which took us back to the halcyon nights of coding katas. It's been a while since we've done a kata, mainly due to speaker evenings, the Christmas break and Alien Invasion.
Why this kata?
Anyhow, back to the kata... We've decided to alternate between coding sessions and speakers at Agile Staffs to gain variety, exposure and generally to mix things up and add a little more structure and predictability. Katas are obvious challenges / activities for single night coding sessions and previous katas have been good fun, and educational for the group.
For January, Jon Willis suggested adding constraints as a way of forcing us out of our comfort zones in terms of language, technology, approach etc. The hypothesis is that, being forced to try new approaches may influence how we develop software in the future. For example, performing the kata without getters / setters strongly guides the developer towards a Tell Don't Ask approach. With this new founded insight, the developer may start to move towards Tell Don't Ask in normal production code which many consider A Good Thing.
Why Clojure as a constraint?
After watching Simple Made Easy a couple of years ago, I've become more and more interested in simplicity and transparency in software development. I've also become greatly interested in CQRS where request channels are separated from command channels due to their considerable differences in requirements (performance, consistency, availability etc). With it's simplicity, immutable state and data focus, I see Clojure as a great enabler for CQRS, and I'm keen to gain feedback and discuss this and wider Clojure use with others.
Further, Clojure's simple and dynamic nature supports fast development using TDD and a great supporting aid - the REPL. Therefore, I'd pretty much chosen Clojure as my constraint before the evening, and Neil (my programming pair) was keen to play with a different Functional Programming language than F# which he has used previously.
How did it go?
It went Okay. Obviously, you expect to be less productive when you place constraints on a development task but raw productivity was never the goal of the exercise.
Within 5 minutes, the basic project (Lein, Clojure, Lein-autoexpect, expectations and Lighttable REPL integration) were all setup. Within 20 minutes, we had the first 5 or so tests passing.
Just as we were gaining significant momentum, we hit a problem with a Clojure function (I forget which) and tried to use the REPL to experiment with clojure.core. Unfortunately, and for the first time for me, Lighttable's REPL support refused to play ball with the basic namespaces. It failed with basic functions like + and empty? which really set us back in the middle stint of the session, and whilst a last minute surge got us through another few tests, we only managed to get to requirement 5 - validating for negatives. I'd be keen to hear feedback from other pairs on how far they got through this kata..
What lessons did the group learn?
Constraints slow you down. Kind of obvious but they really do. Katas, brown bag lunches, code retreats and events like these provide a 'safe' environment free from % complete, Story Points, delivery promises. Productivity and code quality take a back seat to experimenting, learning, and sharpening developer tools. Hopefully those sharpened tools will improve productivity and / or code expressiveness when back at the coal face.
Jon Willis and his pair initially tried No IDE as a constraint. As an mainly C# / VS.Net developer, Jon found this is a significant constraint. They initially tried command line compile / test driving using Java JUnit, and then C#, NUnit. The productivity loss was too great to continue this constraint through the evening, although they saw benefits from this activity, primarily in understanding the underlying compilation and linking process so essential for continuous integration.
After struggling somewhat without an IDE, they changed tack to try 'No Ifs'. This focuses around the complexity and testing issues inferred by conditionals so well described at the Anti If Campaign and by attendee Shaun Finglass's excellent blog post. Again, they found this a difficult constraint considering the challenging time constraint, and simple kata providing insufficient complexity to enable the common polymorphic alternative. However we agreed that it might be a good future constraint to focus a whole evening on.
Due to the sheer ferositity with which most pairs were coding, we didn't put our keyboards down until about 20:50 - a problem as we get kicked out of Staffordshire Univeristy at 21:00. The 1o minute chat at the end simply wasn't enough time to discuss what we have learnt, what we would like to try again, and again, suggestions for future Agile Staffs sessions.
What lessons did I learn?
Using Clojure, and introducing it to a friend with some FP exposure what a good choice. The challenge was interesting, demonstrated some of FP and Clojure's great potential, enforced a significant different approach than Object Orientation would have done and was Good Fun. Many of the supporting tech like lein-expectations, expectations and Leiningen Just Worked and got out of the way of our challenge. However, my choice of using Lighttable was a slight mistake. Not that Lighttable is bad. On the contrary, I've been using it for several months, and it's provided a great environment for Clojure development. However, I chose it as a more friendly alternative to Vim for primarily VS.Net based developers. However, for some unknown reason, it's inability to provide a reliable REPL caused significant issues for us Thursday. I've never experienced this previously, and it has behaved itself today. It was just one of those things which frustratingly limit progress in this time constrained challenge.
When not facing technical issues, we coded quickly. Many of the functions available to us provided obvious, and well known operations that allowed us to deliver functionality fast. Examples include the well known map(), reduce() and filter() functions. Likewise, I greatly enjoyed the lack of ceremony writing classes, and potentially dealing with mocks / stubs whilst delivering reusable expressive code.
I've not seen any other pair's code, but I hope that Neil and my code (on github) demonstrate expressiveness, and transparency to the problem being solved. This is essential to support reasonability - what Rich Hickey states as an essential attribute to software systems . This juxtaposes with Object Orientations concepts like abstraction and encapsulation which attempts to somewhat hide the problem domain behind interfaces. This juxtaposition was one of the main discussion points I hoped to achieve through this session, and whilst that discussion did not happen, I was glad to play in this area with a strong OO advocate - Neil. I look forward to having this discussion in the future...
Finally, I would like to say goodbye and big Thank You to Neil Kidd. Thank you for founding Agile Staffs. Thank you for organising it over the years and don't worry, it's in safe hands ;-)