Introduction to Task-Driven Development

What is a task?

Let me ask you a question first: are you using an issue tracking system? If the answer is yes, then skip this section and jump to the next. If not, keep reading!

So, you do not have an issue tracking system in place!!! Let's get this fixed first. Go and grab one. No, don't start a long and boring evaluation, just go and grab one, any system is better than not using one. In fact, read Joel's test: 12 steps to better code and triple check point 4.

There are many systems out there you can use:

  • Free ones: Bugzilla, Mantis, Trac
  • Commercial: Jira, OnTime, Rally, VersionOne

And many more! The issue tracking systems are meant to track issues, or bugs, but don't limit yourself to only bugs.

Rule of thumb - everything is a new task. Every change you make in your code will have an associated task (or issue).

Yes, it can sound extreme if you're not yet doing it, but please consider it: never do a change in your code again without having an associated task. It doesn't matter whether you're fixing a bug or aligning a button or implementing a brand new feature: create a task for it!

Note: Do not embrace a project management nightmare. Do not try to force developers to make unnecessary effort to keep the issue tracking system updated. The object is just to have a database of tasks, not a PRETTY database of tasks that's super-detailed and complete with nice pictures. Keep it simple.

Note (yep, again): Developers must understand issue tracking as a core team practice, as something that helps them on a daily basis to keep track of what they've been doing. If they perceive it as a management control mechanism, it will turn out to be much less useful than what it needs to be.