Monday, November 30, 2009

Problem with Bug Trackers

I once worked on all manner of quality record systems. Anything from enterprise level ISO9000 incident management systems to team-level bug tracking tools.

The apps were often built under the premise that they "own" the data, so requirements were architected to make them one-size-fits-all solutions with little (or no) attempt to redress the scopes of the complex organizational hierarchy. Concerns of individuals, teams, business groups (or other relatively stable organizational divisions) conflict, and couldn't be addressed effectively by the rigid models. For instance, a hardware engineer could not track a design issue with the formal ISO9000 tool, because reporting the issue to the latter automatically escalated it from a design-phase to-do item to a legally visible "incident" (and notified all managers too).

We knew that teams needed to coordinate amongst themselves and track bugs within their own cycle, but management wouldn't acknowledge distinctions for those areas of application. So most of the needs were addressed through skunk-works tools.

Many of today's to-do list Web sites have the flavor of those skunks-works tools. In particular, the sites tend to see the world as if it were a single flat list of categories, items, or names, rather than as deeply interconnected semantic models. Mostly that's because building semantic models is something few people are prepared to do, and fewer still can justify the cost.
Post a Comment