Someone on Twitter the other day sent me a message asking me what tools I was using when making apps for things like issue tracking, testing, managing tasks in a project, etc. I don’t know if I’m the best example of anything, but I can tell you what’s worked and not worked for me in the past.
You Need to Write Things Down
The biggest issues I’ve had working with others have come when the team isn’t on the same page about what everyone needs from everyone else. Having a daily check-in where everyone gets together isn’t a bad thing, but it’s not a replacement for having an issue tracking and project management system in place.
If you’re thinking this can all happen in email threads: you’re wrong. An email thread is a terrible place for this sort of discussion to happen. People don’t respond, everyone has different habits when it comes to email, and people inevitably mix up 10 different topics into one thread that goes on for weeks. You need a system that allows you to create a task, assign it to someone, and have running commentary on the same page.
The best place to do that is in a dedicated issue tracker, maybe a project management tool, and a good chat system if you’re working with other people.
Issue Tracking
The issue trackers I’ve used and liked are GitHub Issues and Lighthouse. What I like about both of them is that they’re both extremely simple, reasonably freeform, and let you enter enough detail into your ticket to explain what’s going on. Some people like other tools, and that’s fine too, these are what’s worked for me. As a general rule if something gets very complicated I’ll stop wanting to use it.
Both of these will integrate with your source control repo, let you tag issues with whatever you want, create milestones (v1.0, v1.1, etc), comment on existing issues, and assign them to team members. Speaking of teams – you should be using an issue tracker even if you’re just one person. Apps like OmniFocus are great for runway level tasks, but bugs and enhancements are usually more than just a task, and you want to be able to get an idea of how they connect.
What’s great about GitHub Issues is that it’s free if you’re all ready using GitHub, and it does most of what you want. What’s better about Lighthouse is that it does everything Issues does, but a project in Lighthouse isn’t tied to a specific GitHub repo. You can’t have Issues without a repo, so if you have a project with more than one repo (e.g., web backend and iOS app), there’s no way to track things across the two.
I’d recommend giving GitHub a try until you feel yourself bumping up against the walls, and then try Lighthouse.
Project Management Tools
Project management tool like Basecamp or Asana can work well when you have a team and you need a 10,000 foot view of what you’re working on. For individuals or even small teams, I don’t think you always need one. For one person writing their own apps, I’ve only seen these used for procrastination and the kind of task shuffling that distracts people from actually making their thing.
On the size teams that I usually work with, I’ve rarely felt a dedicated project management helped up get anything done faster. Maybe for non-technical project managers, but those people are usually a net negative as well1. I imagine when a team gets to a certain size you need something like this, I just don’t generally work on teams of that size, so I don’t know.
In my experience a good issue tracker can take the place of a dedicated project management app, but not the other way around. The reason is that project management tools usually have a concept of tasks, but usually don’t have the right fields to put in all of the detail you need when tracking new features and bugs.
Group Chat
If you’re working with a team, you should have a persistent chat system. I’ve used Flowdock, HipChat and Campfire. Hipchat has the best native apps, but I prefer Flowdock because it was the easiest to integrate with other things like GitHub, was the hardest to lose track of things in and has the least ridiculous annoyances and limitations.
- Project managers who understand design and development, or at least stay out of everyones butt can be a different story. ↩
