Coding Is Like Cooking

What do you have to do to get me to come and work for your company? Well, it seems a couple of free lunches and some good geeky conversation works pretty well. Of course, it helps if you’re also offering me an exciting mix of software development work, high calibre colleagues and speaking engagements, all on my doorstep here in Gothenburg. So anyway, yesterday I signed on the dotted line for IBS JavaSolutions AB.

JavaSolutions is responsible for the local branch of Sun’s JavaForum, which exists to support Java developers. There are regular meetings with talks and mingle, a bit like GothPy only on Java and without the interactive coding part. Hmm. I might have to do something about that 🙂 JavaSolutions also has a blog that employees are expected to contribute to. So I will have to devise some strategy for what to blog here and what to blog there.

My first appearance in my new role will be at agile2008 in Toronto, Canada, at the beginning of August. I’ll be leading a session about Automated Acceptance Testing with my husband, Geoff. During the rest of the conference I will probably be going to lots of stuff to do with agile development and testing in Java. Having spent the last 6 years working in python, I’ll need to brush up my Java a little.

So I’m looking forward to a fun autumn coding, learning stuff, and getting involved with GothPy and JavaForum. For the moment though, I plan to make the most of the Swedish summer together with two small children.

Last night a group of eight python hackers were drawn into a darkened conference room on Odinsgatan “Odin’s street” in order to exchange little-known information and to take part in obscure coding rituals. To open proceedings, Andrew Dalke shared deep insights into the enigmatic “stackless” python. Later on, fuelled by strong Swedish coffee and cucumber sandwiches, we together attempted the “BankOCR” Code Kata. Everyone present contributed to further our art, and most took a turn working the somewhat arcane keyboard and IDE. By the end we had created a perfect although incomplete code chimera. Despite our considerable successes, it may need further work before any bank would consider taking on our design for their optical character recognition system.

And now I must confess to the part I have played in this pythonic plot. It is the result of scheming between Andrew Dalke, Johan Lindberg and myself. We joined together a few weeks ago to make arrangements for the creation of this chapter of the python community. By some twist of fate, I was designated “temporär ordförande”, or “acting high priest”.

Three hours of pythonic union notwithstanding, everyone present last night agreed that the experiment should be repeated. We look forward to the continuation of our assembly at the second Gothenburg Python User Group meeting sometime next month.

Miranda was born last Thursday, a healthy little girl 53cm long and weighing 3.77kg. Her big sister Karina, (now three and a half) and Geoff and I are all doing well.

I hope to be at home with Miranda for about 6 months, so I don’t expect to write much here for a while.

Test Driven Development (TDD) is a way of programming where you start be specifying a (failing) test, write code until it passes, then refactor. Repeat. This technique has been hugely valuable and adopted widely since it was introduced to the world by Kent Beck and others. The classic way to perform TDD is to specify the tests using the same programming language as the code under test, with the help of a little framework called xUnit. (Replace “x” with the language of choice). But how would TDD look if you used another tool instead of xUnit? Is there a way of capturing the advantages of the approach, but using tests that are easier to write and maintain?

About TDD with TextTest

I begain using xUnit in 2000 and have been improving my skill at TDD ever since. Recently though I have been working less and less with xUnit tests, and more and more with using TextTest tests to drive development. This approach seems to preserve the original spirit of TDD, ie the tests are still driving development, but there are some differences and advantages.

When you use TextTest to drive development, your tests all end up being written in a representation that is separate from your code, ie a kind of Domain Specific Language (DSL). Your tests can be read and understood by anybody who understands the domain of the system under test, that is, they don’t have to be able to read or write program code. You typically don’t write new code when you write a new test, you just specify new desired program behaviour using this DSL. This makes it quick to add new tests, and easy to refactor your code later, since the test doesn’t place any demands on the internal structure of your program (its classes and methods).

With xUnit tests, each test is only working with a small section of code, whereas a TextTest typically drives a path through a whole system or subsystem. This means that you need to use another technique to get fine grained visibility of what your code is doing. Instead of turning to a debugger, the approach with TextTest is to include log statements as you code. Having your application write a log is not a new idea and there are a number of excellent logging frameworks out there. TextTest allows you to not only specify the behaviour of your application in terms your customer will understand, but also control the application logging behaviour. When you make a code change, and your program no longer behaves the way the customer wants, (you introduce a bug), you can turn to the recorded application log to pinpoint exactly where program behaviour deviates from that previously recorded. So a test case consists basically of program input, expected user-readable output, and an application log.

TDD with xUnit is also generally accepted to be a design technique as well as a testing technique. I think there are two reasons for this. Firstly, just the fact of having these tests in some sense forces you to make good low level design decisions. Your code must exhibit loose coupling and high cohesion before you can extract units of code to test. This is desirable, and TextTest does not force you to do it, since it tests at a higher level of granularity. (On the other hand, if you are starting with poorly structured legacy code, where easily extractable units are hard to come by, you can get going with TextTest more or less immediately just by adding some (hopefully) harmless log statements. But I am not talking about legacy code in this article).

The second way in which TDD affects your design is that it forces you to think about the interface to your class before you define the implementation. This is low level design – choice of class and method names, and what arguments you give them. This is useful because thinking about the interface before the implementation should lead to a better, cleaner interface that is easier to use. TextTest doesn’t help much with this either. It will force you to start by defining the interface to your whole program or subsystem, but it won’t help on the class level. So when developing with TextTest we suggest something called “usage first” design. Start with the external interface to your program, and write code as if the classes and methods you want are already there. Then fill in the implementations, always working top down, and defining the usage of a class or method before your implement it. This takes some discipline, but leads to a similar effect to using xUnit.

About Code Katas

A code Kata is an idea introduced by Dave (Pragmatic) Thomas. He points out that specialists in other disciplines do a lot more practicing than programmers do, in order to improve their skills. Others have further developed this concept into the idea of a “Coding dojo”, or a place where programmers meet to practice code Kata together. The website www.codingdojo.org is a resource for these communities, and amongst other things has a catalogue of various code Kata exercises various individuals and groups have worked on.

About the KataMinesweeper screencast

So that is all the theory, how does it work in practice? In this screencast, I demonstrate a PreparedKata of KataMinesweeper, using TextTest to drive development, in python. During development, I aim to work in a Test Driven manner, and I want to develop top down, usage first, in small steps. The idea is that although in real life you may not be so strictly test driven, or exclusively top down, or use such small steps, that it is important to know how to do these things, and they are worth practicing on a toy problem like this.

My aim is to demonstrate what it is like to do TDD with TextTest, and how you might solve this code Kata using the python programming language. If you would like to comment and give me constructive feedback on this screencast, I would love to hear from you.

The screencast is in four parts, and I estimate each part will take you about 10 – 15 minutes to view.

• KataMinesweeperPart1

• KataMinesweeperPart2

• KataMinesweeperPart3

• KataMinesweeperPart4

(Note: This screencast was created using Wink. In it I use Windows Vista Home Edition, Easy Eclipse for LAMP version 1.2.2 and TextTest version 3.9.1.)

I’ve listened to a lot of Bob Payne’s agile toolkit podcasts and I think Bob is pretty poor at interviewing people, although he does interview some very interesting people.

Bob clearly doesn’t plan his interviews or think in advance about what questions to ask. He just seems to sit down and chat with people as if he were in a bar somewhere and happened to have a microphone on the table. He often assumes his listeners know the background of the person and what is being discussed, and doesn’t ask people to elaborate. Bob also tends to interrupt the person he interviews and presents his own opinions rather than getting them to elaborate on their views.

It’s a far cry from the other podcasts I like to listen to, where the interviewers are really professional, for example Bob McDonald on Quirks and Quarks, or Greg Galant on Venture Voice.

Anyway, as I said, Bob Payne does interview some interesting people. I listened to this podcast today, where he was talking to Dave (Smalltalk) Thomas. They rambled on at some length about different programming languages and platforms, and Dave started talking about what he called “boutique” languages, APL being a case in point. What he said about this community totally corroborated what I discovered when I met a couple of APL programmers recently. There aren’t that many of them, they mostly work for financial institutions, and they collaborate very heavily with their business users/domain experts. This article by Stephen Taylor gives a flavour of how this community works, and talks about a kind of pair programming between an APL expert and an end user. It sounds really cool, actually, and highly productive.

Bob Payne is clearly a Ruby community member, and Dave (Smalltalk) Thomas is in the Smalltalk community. I mostly count myself part of the Python community these days. Each programming language community seems to have its quirks and personalities. Of the communities I’ve hung out with to any extent, I’ve noticed that the Ruby community seems to be really friendly and welcoming to newcomers, whereas the python community can often seem very aloof and somehow intimidating. The Java community is so enormous it doesn’t seem to notice other communities exist, or have anything useful to offer, although it’s a few years now since I’ve hung out with them, and they may be moving on.

I think these “community personalities” arise partly because people move between language communities slowly and infrequently. Once you get good at a particular language it is always easier to stick to it than learn a new one. In their first book the Pragmatic Programmers advise you learn a new language every year, but I’m sure only a vanishingly small proportion of programmers manage this, and even fewer go on to get involved in more than one language community.

I am really interested to see what will happen with all this talk of Polyglot programming that (amongst others) Neal Ford has been talking about – they predict that in future your average system will be built from a number of parts written in different languages, each suited to the task in hand, running on one of the major Virtual Machines – .Net or the JVM.

If this does indeed happen, I think it should result in a major shakeup of the way programming language communities operate and interact, and I believe this will be really positive for the industry. At the moment I feel like their are pearls of wisdom hidden in each separate community, and not enough people are moving around to pick up the pearls and distribute them to the others. Dave Thomas must be one of the few who has insight into more than just one. Maybe one day more programmers will be pairing with end users just like the APL guys have been doing for years.