Chapter 1. Background

The design and implementation of any nontrivial software development project involves hundreds of issues, falling into various categories. Certainly the most often celebrated is the defect report, and to satisfy the demanding task of tracking hundreds or thousands of defect reports, various bug-tracking systems have evolved in the software development community. These tools offer more features and capability than a simple "list of bugs", but they fall short of expectations and capabilities in a few notable ways:

  1. They are difficult to install and configure. While this author has had little experience with commercial bug-tracking systems, the open-source alternatives have been confusing to install and configure. Multiple attempts at using GNATS, for example, have all met with failure despite repeat installation, recompilation, and close perusal of the documentation, and involve issues (such as creation of user accounts/email gateways, installation of system daemons, etc.) which may be unnecessary for smaller development efforts.

  2. They assume medium-to-large-scale requirements. It could be argued that only medium-to-large-scale development efforts require an issue-tracking system, but even small teams and individual developers could benefit from such an application. However, the alternatives do not always support this, forcing system requirements which may not be appropriate. GNATS, for example, requires a dedicated user account for any submission of problem reports; bugzilla seems to be very web-oriented, making it impractical for small teams without a dedicated and cooperative website.

  3. They are relatively inflexible. Most of the available products are defect-tracking systems; they allow the administrator some degree of flexibility, such as allowing different defect states, etc., but are still essentially defect-tracking systems. But development projects deal with many classes of issues, such as wish-list items, use cases, or functional requirements. Many systems are unable to offer enough flexibility to implement these.

  4. They are isolated products. To an extent, a self-contained product is a good thing, because it implies no dependency on additional tools or applications. Because of this, most of the tools available remain "separate" from the development effort; they do not integrate with revision control, etc. This not only separates the issue database physically from the development repository but also means that many of the procedures used to protect and maintain files in the development repository (configuration management to protect and track changes in source code files, or network synchronization of physically separated issue-collection sites, for example) must be duplicated for the issue-tracking database.

As a result, the available tools, while powerful and useful, are often not used for small or medium projects, and even when usable do not satisfy many of the requirements or expectations of a simple, flexible issue-tracking tool. An arguably better solution to the problem of issue management should:

  1. Be easy to install and set up for novice administrators. For small and medium projects in particular, project managers need a very simple installation and configuration process for a default issue-tracking repository; a simple installation/setup should take no more than a few seconds and should be very simple. A detailed knowledge of the product should not be necessary for immediate (if somewhat limited) use. This will allow neophyte users to develop the habit of using tools to systematically track and maintain issues, and allow them to refine that habit later (rather than presenting a barrier to entry which prevents the habit from developing in the first place).

  2. Require very little from the system for at least basic use. If the tracking application is installed and available to the novice user, such a user should be able to set up the default repository and begin using the application without needed special resources which would require coordination with the system administrator, such as a dedicated email account, website, etc. No one should need to consult the system administrator to track issues on their "Hello, World!" project.

  3. Be flexible enough for expert administrators to handle unforeseen issue types. With some effort and study, administrators should be able to configure the tracking system to handle different issue types, or to modify the existing issue types in new ways, such as adding categories, tags, or attributes, or even entire fields, and non-text attachments to these issue reports (particularly handy for issues with graphics programs, or to attach GUI mockups to use cases, etc.).

  4. Be part of the development effort, not separate from it. The issue-tracking repository (a set of directories holding submitted issues and other germane files) should maintain a strong connection to the development effort itself, ideally sharing space in the development repository (the set of directories holding the total of a project's data) and being subject to the same tools and processes used to control and manage the rest of the development effort. The tool should also be scriptable so that it can be driven by the same scripts that drive the rest of the development process a make target, for example, could generate metrics from the issue-tracking repository). For the purposes of discussion, the configuration management software used will be CVS, as it is well-known and widely-available, but YakTrack should be scriptable enough to work with any reasonable configuration management software.