Because you’ve got issues

Posted on 8 January, 2011

This is the second post for iDevBlogADay. In the previous one I hope to have successfully outlined why a knowledge management system built with a wiki is useful for any iOS dev. This time I want to persuade you to think about your issue (or bug) tracking process.

The Problem

Even if we try, no app will ever be bug free or remain unchanged. Over time requirements may change or other features creep up and so there is a constant need to maintain a list of todos that are related to developing the app. These todos do not emerge in succession right from the start. They can occur any time. While some of them are just mundane tasks others will have varying priorities. Be it a last minute bug that you found right before submitting the app or an useful user request later on – you will be constantly challenged to keep track of the development process. If you don’t – bad things will happen (and that’s common wisdom so I won’t repeat it here). ‘Because you’ve got issues’ is a slogan printed on t-shirts handed out by Atlassian (creators of Jira) and sums up the very essence of this post.

But what’s wrong with the status quo?

As with the previous post low tech is still a valid alternative. Yet again the time you save while poping out another .txt file on the desktop to dump todos for your app, will be spent later when you need to retrieve and prioritize these todos. This may be at the unfortunate time around the end of the development cycle when time is scarce and the crunch mode begins to leave its marks on your stamina.

Issue tracking

We decided to use a web based issue tracking tool. As with the wiki, the big advantage is its distributed availability and ease of use. Especially since we are working mostly independently from home. At its heart an issue tracking tool is just a specialised task management system tailored for the needs of software development. The base consists of separate issues. Each issue contains a bug description (or feature request, or user story). Ideally it has additional metadata attached like the version it belongs to, the component, the expected fix version and so on. This is the most important part but sadly also the hardest one when it comes to introducing the system. This time the adoption of the issue tracking tool was encountered by much more resistance then the wiki. Trung and I are still not on common ground when it comes to creating issues…

There are two main use cases for the issue tracking system. The first one is to gain an overview about the project. This is accomplished through the intricate filtering of issues. After all everything that is presented to you while operating the tool are just filters that display issues in interesting (and hopefully insightful) ways. The second use case is to store issues (and potential feature requests) so they are not forgotten. Again, filters come in handy when choosing the next feature that has to be worked on. Without metadata no proper sorting is possible. This greatly diminishes the advantage of an issue tracking tool.

Each new iOS project starts as an issue tracking project. We add the proper components following the MVC pattern as well as useful additions like “Text” (for translation related tasks as well as app store texts) and “Marketing” for well… marketing stuff. Versions are defined and we keep them in sync with the real versioning numbers for the app in iTunesConnect. For every bug we find, another issue is created and instantly prioritized. Although most entries are optional while creating the new issue – just their mere existance forces us to think about when and where the issue belongs to.


To be honest, the first time I encountered Jira I wasn’t very impressed. Even worse – I didn’t like it at all. Much has changed since then with both – Jira and my attitude about issue tracking. Atlassian has put quite some UI love into their (presumably oldest tool) and made it very accessible. Just like with the wiki software Confluence it follows the same usage patterns albeit in the context of issue tracking. This time I didn’t look for alternatives. I have used Mantis before and through my open source past Bugzilla for sure – but that’s all to it. However I am glad that I sticked to Jira – some gems are only discovered over time:

Roll your own or hosted

Just like Confluence, Jira is written in Java and has strong support for Linux. There is a hosted option or you can roll your own. Jira is comercial software and (sorry for saying it over and over again) – but just like Confluence – the ten user license is available for 10 bucks (all proceeds go to charity). Again just like… Atlassian uses it’s own tool to manage the further development of all other tools. There is also a huge community built around it and feature requests get instant attention (for the better or the worse if it is a duplicate request).

It’s like driving a Porsche Cayenne

Jira got its better looks quite late but for a heavy duty issue tracking tool it is pretty and extremly flexible. Besides basics like email notifications, integration with revision control tools (svn, cvs, perforce…) – there is something for everybody. Filters that can visualize just about every mind boggling project state, plugins for the fancy (agile development to mention only one of many), OpenSocial gadgets, fine grained security roles and so on. Workflows that define different states of issues with built-in logic (and sensible defaults) make it possible to customize Jira to fit way more than just the purpose of issue tracking. If you want the full firehose of feature overload:

But there is more. Especially on the keyboard shortcuts front. Check out my following very short video showing some Quicksilver-style shortcut jugglings.

YouTube Preview Image


There is no way of saying that you should use an issue tracking tool because if you don’t, you are clearly making your life harder than it has to be. I hope that this post outlines why there are many advantages when using a web based tool and especially something like Jira. Creating apps is complex enough and needs time, so every tool that helps to reduce its management overhead is a valuable addition to every iOS development toolbox.
Next week I will pursue the ‘holy grail’ of integration when combining Jira and Confluence.

4 Responses to “Because you’ve got issues”

  1. Dad
    Jan 08, 2011

    I have to admit that I’m in my first experience with Jira and I don’t like like it either. It just feels like a collection of features all slapped together with no cohesive design or usability oversight. Maybe I’ll like it more the second time I use it :-)

    Fogbugz from fog creek software has a free account for up to two users on their hosted system. For the single person or two person indie shop it’s a good option to consider with tracking, integrated wiki, sophisticated built in email to tickets & tickets to email handling for customer support tracking/handling. Also integrated with their mercurial source code hosting service Kiln.

    Trac from Edgewall Software is another option that can generally be installed on your own server of found combined with svn/git relatively inexpensively. It has nice integration between the built-in wiki and tickets making it easy to link back and forth between the two. I’ve used for inexpensive hosting (free with ads, < $50/yr without).

    Lots of options really.

  2. paul
    Jan 08, 2011

    You’ve persuaded me. :) I went with Dad’s suggestion though and signed up for the free fogbugz version…

  3. Robert
    Jan 11, 2011

    I’ve had the unfortunate experience of having to use JIRA where I work for the past few years. It’s pretty horrible. A very cluttered UI that feels very clumsy to use.
    I can clearly tell it’s a product that is sold to enterprise companies because over the years it’s gotten more and more junk thrown into it without a clear vision of being awesome.


    JIRA is the ‘Your Company’s App’

    If you want a more sleek sexy bug tracker, try the new

  4. [...] This week I’d like to show you how we manage feature requests for our apps with Jira. If you want to know why Jira is great, see my last post. [...]


  1. [...] This week I’d like to show you how we manage feature requests for our apps with Jira. If you want to know why Jira is great, see my last post. [...]