Blue Screen of Death


Last week I had the enormous pleasure of attending a meetup in London to chat with some other iOS developers. My motivation was largely to get some early reactions to ther CardBoard app. One of the most helpful people I ran into was a UX specialist called Don, who is known somewhat ominously as the ‘code breaker’.

He quickly grasped how the application works and then he did something I’ve never seen before. He started stress testing the app by working it far harder than I’ve done to date. Rapidly adding dozens of sections, deleting cards, adding boards, adding cards to boards and so on with stunning rapidity. In some ways it was like watching a deranged toddler running amok in a playroom.

It’s a style of testing that ideally suits a mobile device. Interacting with a desktop app is intermediated via a keyboard and mouse, and web apps sometimes have a built in delay as pages get downloaded from a remote server. It’s also a style of testing that proved to be highly effective – three bugs found, two of which were so minor that I was able to fix them on the way home, one slightly harder that I fixed this weekend. With any luck I will bump into Don the Code breaker again and see if there’s anything else he can ferret out. If CardBoard can survive him, I expect it can cope with most people.

The whole experience with Don reminded me of a comment a collegue made about a web application I was involved with over a decade ago. He said that although positive comments give you a warm fuzzy feeling – it’s actually the negative comments that help. Telling me that flipping cards over is fun is nice, but telling me that the settings card background has mysteriously gone black is helpful.

Of course it also makes me feel like a complete fool, but ‘why stop now ?’ I always say.

I have a couple of minor issues that I hope to sort out prior to giving this to the first of the alpha testers. All but one is me simply wanting to tidy up architecture and tidy up rough edges that worry me – but are invisible to users. The visible issue relates to devices dropping off a network and it’s simply a piece of boilerplate code that hasn’t been copied over from the prototypes.

I’m gritting my teeth again this week and putting these in prior to adding beta features – which are the ones that make this a really useful app.



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.


18th Century man

I set this blog up in the autumn of last year in anticipation of writing about an iOS app that I had written to help me with my lifelong struggle against my weight. Having done so, I discovered that the app wasn’t giving me a great deal of help over what I was already doing, and secondly I had worked out the answer to a technical question I had been worrying about for about 6 months.

And so silence fell.

…what has actually been going on is that I’ve frantically been using my spare time to implement the new app, rather than writing about it. It’s still a work in progress but a couple of weeks ago I was able to make a video of it in operation.

Things have moved on sufficiently from this point that I’m now almost at the point of producing a second vlog, and so I can post the first in some confidence that I’m going to have more to say.

Why 18th Century ? It turns out that the humble index card was invented by Carl Linnaeus (1707 – 1778). He used index cards to bring order to the vast collection of biological information that he was trying to systematize.

On CocoaPods

At first glance the CocoaPods library management system seems like a little bit of extra ceremony, an otherwise obscure configuration file that adds to the complexity of an OSX or iOS build without offering any obvious advantages. It does replay a little bit of study though.

Consider the one way of including an open source library in your build from Github.

  1. Google the library name to find the Github location.
  2. Download over the zipped source code.
  3. Unzip it and move it into your build directory
  4. Add the file to your XCode build 
  5. Repeat whenever the library changes

or with CocoaPods:

  1. Add the line ‘pod <whatever>’ to your Podfile
  2. type ‘pod install’

The CocoaPods system needs to be installed on your development Mac first of course. Here’s a handy Ray Wenderlich tutorial on how to do that. Note that Mountain Lion will throw an error about documentation while doing this. For the purposes of CocoaPods, that error can be ignored.

Return of the Native

I’ve been creating iPhone apps in a casual way since 2010. I’ve currently got 3 in the AppStore, another one in alpha – the Shangri-La diet timer – see my other blog for details, and one more in the early planning stages.

They are all native objective-c programs event though I’m perfectly comfortable with the alternative HTML5 website approach.

Until fairly recently, I made this choice without a great deal of introspection.  I write code personally and professionally, because I’m curious and interested, and for me that requires new ideas. I’ve got lot of experience wrangling HTML and HTML5 but only a couple of years with Cocoa, so the Cocoa way generally wins by default.

However, a friend of mine has been talking about a cross platform project for several months and the technical approach has never been entirely clear. Do you create a mobile website that in theory works on iOS, Android, and perhaps Windows 8 in days to come ? Or do you create a native version of your product one per platform ?

To my mind, the answer has never been entirely clear. Its only in the last few months that I’ve formed a definitive opinion, which is as follows:

Unless you have a content heavy product where the content is changing every few hours – go for native.

The fundamental reason is that on a mobile device or tablet, HTML5 generally represents a compromised user experience and it’s unlikely to improve for iOS or Windows in the near future. There can be no doubt as to the current state of affairs – Mark Zuckerberg’s remarks on the Facebook app may have opened the floodgates on the question, but the general discussion has been going on in the background for some time now.

I sat through a talk held in London last week by one of the people involved the the original ‘The Week’ – it’s a native app. During the Q+A session, the question of HTML5 v. Native came up and he mentioned that the FT took the HTML5 approach and had spent a great deal of time an effort trtying to replicate native mobile look and feel across platform with HTML5. To be fair to them, they seem to have pretty much reached their goal, but it seems they achieved that at huge cost.

If that’s the current situation, why won’t things get better in the future ?

It’s simply that there’s no economic forces driving Apple (and that perhaps will be driving Microsoft) to improve HTML5 beyond the current point on their mobile browsers. Every app that comes onto a mobile via a clever web site is an app that didn’t come through their app store and thus represents an opportunity cost. There are no laws requiring a company to implement a standard perfectly, and Microsoft in particular has a long history of slightly odd interpretations of public standards. Google of course would like HTML5 to work properly everywhere on mobile and it certainly will do on Android. But if a technique only works on Android, that’s not cross platform.

I can’t see this situation changing.

Which leaves the question of rapidly changing content, why the exception ?

One of the things I find very annoying about content sites is that when I happen to hit a story via a mobile browser and it offers me the ‘opportunity’ to acquire their mobile app – which is native of course. This is the point when my blood pressure soars and the urge to spit comes hurtling down from the brain. First of all, the opportunity is invariably in the form of an alert which I have to dimiss before doing what I wanted to do which was to read the story.

Second of all, if the content is changing rapidly, I almost certainly did not arrive directly but either by a news aggregating web site (Hacker news, reddit), or an aggregating app such as Flipboard, Tweetbot, or Firehose. I’m certainly not looking to read other stories on that destination site, just because they are on that site. When and if I come back again it will be via my aggregator.

I don’t want my tablet covered in apps, however lovely their UX, which simply give me content from the or whatever. So all they are doing is annoying me and making me less likely to look at the accompanying adverts.