Monthly Archives: February 2013

In Living Colour


Since I last posted on this subject the intervening fortnight has been filled with the invisible – and slightly tedious – fixing of minor bugs. The sort of work that doesn’t impact the features that the app offers, but does mean that it works as expected in a reliable fashion.

Technical backfilling of this nature goes on with apps all the time, and there’s always the temptation to add one more shiny feature instead of trying to work out why (for example) cards with emoji characters are not moving properly between devices. They do now of course. Sorting that one, and a collection of similar annoyances takes time. It’s important to do it because it allows you to add new features with some confidence that the whole edifice won’t simply collapse in an untidy heap.

Also it’s character forming.

CardBoard has now reached the point where I’m using it myself on a daily basis, and I will be looking for a collection of brave Alpha testers. If you would like early access and you have an iPad2 or more recent, running iOS 6, you can DM me on twitter (@adwelly) or mail me at andydwelly at gmail dot com.

Some notes on Test Driven Development

(posted with permission from Jon Reid at

I must of first heard about TDD around five or six years ago, pretty much as I was taking a temporary furlough from IT to set up a microbrewery. When I came back to IT as a profession after around three years away I was working with Objective-C in Cocoa and Cocoa Touch. This is not an encouraging area to try TDD because the majority of iThing programs are highly  focused on UX. My  impression was that TDD does not have a lot of leverage in this area. It struck me at the time that Behaviour Driven Development (BDD) might be a better choice and indeed I’ve made serious use of the Kif suite in the past.

Forward to the present day, when I have a component of a product suite, relying on some UX software that already exists, and some time to make an experiment. I was inspired by some postings and a screencast by Jon Reid at . He has a series of amazingly helpful screencasts on how TDD can be used in a non trivial way, and how it can be used with the pretty ubiquitous UIView and standard UIControl objects that litter the Cocoa Touch workspace API.

At first progress was almost painfully slow. I kept track of things and was horrified to discover that my total output for the first day was a risable 15 lines of production code along with around 100 lines of testing code. To be fair, the day did involve a certain amount of time reviewing the screen casts, downloading libraries, and so forth. Unfortunately by the end of the week I was still only managing 50 – 75 lines of production code a day.

I mentioned this in passing to Jon Reid himself – he was kind enough to respond to a technical query – and he told me that it takes around three months to master. Three months! I’d budgeted three days….

Well, perhaps that was naive of me, and in fact the early results were intruiging enough to encourage me to persist. What had happened was that after several days of TDD, I’d written a single line of code that caused a cascade of actions. The impact involved five or six classes, a remote server and some tricky failure modes. I would normally expect to write the final line and then fire up the debugger to get it to actually work.

Except that it did just work.

I haven’t written a piece of code that worked first time, since I gave up functional programming languages so this was a pretty notable event. On the other hand I did have to balance the substantial effort and cost involved in getting this far. I’ve been able to get a rough and ready measure the costs involved because I chose to recreate one class that I already had available from another non TDD project.

My original class had 32 LOC in the .h and 111 LOC in the .m files (excluding blanks and comments). My TDD version had 32 LOC in the .h, 94 in the .m, and 246 LOC in the tests, effectively TDD was tripling the effort involved. The production class was actually slightly smaller because it did not contain the fairly involved description method that was in the original. Since I wasn’t doing a lot of logging or debugging, it was never needed. My impression is that this ratio has held true throughout the project so far.

I think at this point, if I’d been asked anything about the issue of code quality I would have claimed that the actual code produced was marginally better. My TDD code certainly handled errors and failures better, but had poorer information hiding and some dependency injection that I would not normally have bothered with. So six of one, half a dozen of the other.

Then my tests found a bug that I don’t think I would have spotted until the code hit the field.

It was a complicated problem, revolving around caching, and although I can’t prove a hypothetical, I’m pretty sure that I would not have noticed the issue until the code was in the client’s hands, and then only under a fairly unusual set of circumstances – changing a server IP address for example. In other words, the kind of problem that appears after around a long period of constant use, and can only be solved with a great deal of forensics, and long after I’ve forgotten how everything works. The sort of bug that costs. Big time.

This has allowed put a different perspective on my views of the costs of TDD. Before my experiment started I believed that TDD was expensive in terms of time and developer effort. At this point my position has shifted, I now think that TDD shifts costs around. It makes the creation of code more expensive but reduces the costs of debugging and deployment. I can’t say at the moment whether the resulting systems are cheaper over the long run (although there are certainly plenty of people out there who will make that claim). I’m still of the view that trying to do a lot of UX tests using TDD is hard.

On the other hand, I am convinced that the overall quality of my code is improved. Right now I’m planning to use TDD _and_ BDD in production systems in the future, and fire and forget for my prototypes.


Work continues on the CardBoard app, but there’s nothing much to see this week. I’ve been concentrating on improving some internals so that there is a firm base for the next step.


Slouching towards Kanban

It’s taken slightly longer than I intended to get to this stage. This of course is partly due to the slippery nature of software development itself – but in this case, it’s also down to the fact that the end of January is tax season in the UK, and in my case this co-incided with an internet outage which took the best part of a weekend to sort out. I still don’t know the reason but I certainly can’t complain about the level of support I’ve had from my ISP. If you happen to be reading this in Britain and you are looking for a new internet provider – I recommend Zen Internet.

The App still has all the features that were in the previous video – inter device card transfer, flippable cards, sub-boards and so on. The most obvious addition is that you can now add sections – sometimes called swimlanes – to a board as well.

As with boards, a swimlane can be renamed, and deleted if it is empty. They also have a number at the beginning – that’s the total number of cards in this swimlanes and it includes any cards on subboards in this lane too. So if a lane has two cards in it, and also has a subboard with five cards in it – the number on the lane will be seven.

Why bother with a number ? Although I think this §app will be used in a variety of ways, I’m also hoping that it will prove useful to practitioners of Kanban. Kanban, pronounced conbon’ is a time management and project management practice that originated with Toyota. There’s a lot of information out there but to summerise it, it relies on vizulizing work, in this case on index cards, limiting work in progress, and moving cards between swimlanes as work proceeds. You can see me doing this in the video as a card move’s from my ‘To Do’ area, to ‘In Hand’, to ‘Pending’, and on to ‘Completed’.

You can apply the same idea to agile software development, the swimlanes in this case might be User Stories, Design, Code/Test, QA. Endless variations are possible depending on your own particular way of handling work.

One point that Kanban is very clear on is that there is always a limit on the amount of work in progress and this in turn limits the number of cards in any particular swimlane. This immediately leads to the question of whether or not CardBoard should enforce limits ? I’ve chosen not – as you can see here. There’s always a balance to be chosen on how prescriptive a piece of software is made, and I think we often get this balance wrong. If I insisted on capacity limiting lanes, the users would run into the following issues:

1. Non Kanban users are inconvenienced
2. Kanban users who need to go slightly above the limits are inconvenienced
3. There needs to be a way of specifying capacity
4. there needs to be feedback when you try and move a card into a swimlane that full
5. You’ll probably need a way to adjust capacity,


In real life, its pretty obvious that a real notice board with real index cards doesn’t have enforced limits on capacity, and doesn’t really need it either. An overcrowded lane would be obvious. In CardBoard I’ve chosen to go down that route too.