You are quite correct. It is always a bad sign if you have tasks that are captured but never actioned ... (Almost as bad as never capturing the problems in the

You are quite correct. It is always a bad sign if you have tasks that are captured but never actioned ... (Almost as bad as never capturing the problems in the first place) However, it is just as easy to have unloved, unwatched tasks festering in JIRA or Trac as it is to have TODOs festering in the source code. (I've seen both). The form in which the problem manifests itself isn't terribly important here ... or at least, its' less important than the solution. What is needed is a robust and active process to triage new issues; to action items that really are a problem, and to record the decision to discard problems which are not worth resolving. If you have this process in place and working, then you don't need to care as much about where the tasks are stored: SQL database or text file or Excel spreadsheet ... all can be made to work. Now, personally, I would argue that having a structured, human-readable and editable serialisation scheme, under version control and configuration management, usable for tasks, requirements and other items of engineering documentation will (does) make it easier to build the level of comprehensive scripting and automation that (I believe) is required for a truly disciplined engineering process.