Any discussion about the relative merits of task tracking software is moot because of fundamental discrepancies with regard to tracking tasks. Programmers don'

Any discussion about the relative merits of task tracking software is moot because of fundamental discrepancies with regard to tracking tasks. Programmers don't need task tracking. They have an in-head priority queue of stuff that needs to be done, and often doing that stuff will cause insertions into the queue that will completely reshape it. If you make a copy of that queue into a system the result is a pixellated representation of the original data and it's probably outdated by the time you finish making the copy. Programmers might have a TODO.txt or a post-it somewhere to remind them to not forget some unrelated stuff, but generally once a programmer knows what needs to be done and why the work will partition itself, in the right order, and into right sized chunks. The queue is rather alive and zooms in and out all the time. Managers don't need task tracking either but they think they do. What they need is a way to measure progress and completion. A manager's task queue is a very different queue from what the programmers have in their head. Most of the time, you can't map items from the programmer's queue into the manager's queue. The reason is that in the programmer's queue all items take the time it takes to complete items and thus items come in different sizes. In the manager's queue the items have time estimations and progress percentages and they're split into manageable chunks of time; if not hours at least usually days. So, managers get this idea that they can ask programmers to maintain a copy of their internal queue and save time and effort by reporting progress from there. Usually this takes the form of a task tracking system. The pixellated result that managers get from the programmer's queue is data which managers then need to reinterpret as information when reporting up. All they need to report back to other managers and higher ups is the progress, how well the work is within the estimates and when will it be complete, and a few answers to "whys" of what's causing delays or why something new needed to be done. But the programmer's queue has none of this information so dilbertesque creativity is unavoidable during converting programmer items to manager items, dragging everything farther from the truth especially if the managerial copy is ever fed back to engineers. The programmer will think the result is ridiculous and doesn't at all match what's in his own queue. The manager can't see what's exactly wrong with it except that programmers are bad making estimations and the tasks are badly scoped and larger than they were planned, thus completion is prolonged each week. A signs of this happening is that tasks being tracked don't match with the tasks being worked on. There's some overlap but some tasks are suspiciously simple while others are too vague, and there's unreported invisible work that sometimes takes the majority of the wallclock hours of a week. The programmer could only ever supply correct information when everything is done and tested while at that point the manager doesn't need it anymore as he can report back "100% complete". If the programmer is asked to provide more fine grained subtasks he will either spend more time pleasing the manager rather than doing real work or he will first work with no plan and no tasks for quite some time until he has enough information to add the appropriate subtasks into the system. Fine-grained tracking also eats into the free flow of the in-head queue of the programmer: if rearranging the work queue (which happens all the time) gets expensive it creates a barrier to let the work flow towards completion. The programmer either gets stuck with the existing tasks or disregards the tracked tasks completely and continues alone where the path of code takes him. Regardless, the data in the manager's queue will certainly end up being inaccurate, incomplete and outdated. Programmer also has to do extra work simply to work around and between the manager's queue and his own queue. No system can fix this. Good communication is the key, and if you have that you don't want a system to make it slower. Task trackers are useful for individuals to keep things ordered to satisfy their own scheduling needs, but they don't solve the inherent gap between managerial schedules and programmer schedules.