I didn’t make it to RailsConf in New Orleans, but my co-worker Dominic did. He brought my attention to a slide from Zach Holman’s presentation “How GitHub Uses GitHub to Build GitHub.” It’s a great - even inspiring - presentation. If you work on software projects, you should click through it.
Now for the slide that got my attention. Well, really it’s two slides, a comparison of the Redmine issue form and the Github issue form.
From an information design perspective, there’s no contest: Github’s form is simple and well designed. All the optional data (assignment and milestone) is subtle and accessible via dialogs. Redmine’s form is an explosion of ill-defined options, and Zach’s annotations on the slide are a pretty fair representation of the cognitive process of navigating the form.
First, a little background. I assume you know about Github - if you don’t, you’ve probably stumbled on my blog by mistake, and you'll probably want to back out slowly, without making any sudden movements. However, you might not know about Redmine. It’s an open-source ticketing and project management application based on Ruby on Rails (version 2.3). As one might (uncharitably) expect of an open-source project targeted at end users, the user interface can be somewhat counter-inuitive.
Zach’s presentation makes the case that you don’t need additional features - they’re just a layer of complexity that gets in the way of your work. I agree that it’s a good exercise to identify the simplest system you can get away with using - because it’s true that anything else is wasting your time and consuming your cognitive resources.
However, once you outgrow a simple system, you’re spending your time and cognition managing complexity (manually) with simple tools. If there’s not a way to transition to a more complex system that meets your needs, you’re stuck with that manual complexity, which can be a bigger productivity tax than underutilized system complexity.
That’s not to say that you shouldn’t use a simple system, but there are definitely reasons you might not want to. If you know that your project manager is going to want to look at a list of issues that your staff is currently working on, it’s helpful to have an issue model that supports a status of ‘in progress’. Also, I’m not confident that in the context of hundreds, or thousands, of issues that the most critical issues really do reliably float to the top - it’s helpful to have a way for a project manager to set priority for a ticket so it shows up emphasized to a developer (at the top of a list, for example).
These examples are obviously inspired by features common to ticketing systems (status and priority), and you can accomplish something similar with Github’s issue tags. But that doesn’t smell good to me - it’s exactly the kind of wrangling complexity with simple tools that I turn to software to avoid! Why shouldn’t a todo list be stored and edited as plain text? Well, your grocery list can - heck, you could even put it on paper! But it doesn’t have any assignees, priority, or completion, which the issues in your project often do. (A grocery list isn’t meant to be a frivolous example: it’s a project of limited scope that’s intended to be accomplished by a single person.)
Of course, we don’t want to reflect every aspect of our real-world process in our model - that way lies madness. But every project does have a process, even those that claim an ad hoc processlessness, and I think it’s worth spending a little time charting the process and identifying the parts that can be built into your systems. As a developer, I shouldn’t be constantly assessing and juggling tasks: the system should be able to point me to what should be done next. That requires some knowledge of my process to be baked in.
Redmine is pretty clumsy in a lot of ways. The issue form design Zach used in his presentation is probably one of the most glaring examples. But in its defense, it’s extremely customizable, down to the ability to modify the code that’s generating those ugly forms (it is open source, after all). Almost all of the bewildering options in that form are optional, and a better form design could hide them by default or remove them completely. Working with Redmine, I would recommend discussing with your team which elements of the issue model are necessary, hiding everything else. There’s likely a way to collect the meta-information needed to support your process without getting in the way of getting work done.
With all due respect to Merlin Mann, and so much is due, while a priority may be observed, not assigned, the subjectivity of who’s doing the observing matters.* Everyone working on a project has biases that influence what issues they’re going to pick up next. For example, I know there are times when I want to avoid an important issue: it’s a feature I’m not crazy about, it’s part of the code that I’m tired of working on, etc. Sometimes a priority really is assigned - the project manager needs a way to put a thumb on the scale to help inform a developer’s decision of which one issue to prioritize, at this moment.
* To be fair, it’s pretty clear from his article that he’s talking about the paradox of managing your own priorities, not of handling a project workflow.
Some elements of the typical issue model do encourage pointless meta-work. Adding a due date is silly for most issues, and inspires the kind of inflexible granularity that’s well worth mocking. But there I’d like to point out the distinction between resisting meta-work and foregoing the possibility of collecting meta-information. I would hope to steer a middle course: choosing a system that can be simplified to reduce friction (meta-work) but can be extended to support and speed my project’s workflow.
The advantages of Github are legion: it’s almost always actually working, you know it’ll scale, it’s got a fantastic source code browser, and pull requests are totally rad. I love Github, and I have a bunch of projects there.
But here’s the thing: Github, while completely awesome, is not someplace I like to manage a project’s tickets. Redmine, while hideously cumbersome by default, is. There’s definitely personal preference at work there, but I think there’s a reason to embrace complexity in systems - when it’s helping you get your work done, by managing some of that real-world complexity so you don’t have to.