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.
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.
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.
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.