[p4] Large development defect management (was: P4 with BugZilla, TeamTrack or ????)
John-Mason P. Shackelford
john-mason at shackelford.org
Thu Mar 24 09:20:27 PST 2005
> I guess the point is that TeamTrack will do everything Bugzilla
> (and its ilk) will do but not vice versa without considerable
> scripting and possible source code changes.
I don't believe this to be true, though it may appear to be at first. In
my experience subtle differences in the way a tool operates--the sort of
differences which never make it onto a feature list--can have dramatic
consequences in usage patterns and productivity. Responsiveness, for
instance, has significant impact on the way a user interacts with a UI.
It's in these subtle details we see significant differences between
TeamTrack and Bugzilla.
For example, even with big iron behind it and a carefully tuned
database, TeamTrack performs poorly compared with Bugzilla. As a result
users resist it and we capture fewer issues. The tool doesn't become
part of the rhythm of day-to-day development the way Bugzilla does for
the Eclipse project. Eclipse developers create and track far more issues
than we do, because the time it takes to open an issue, break an
existing issue into several others with dependency relationships, etc.
is a fraction of the cost of doing similar operations in TeamTrack. As a
result, TeamTrack users find other more efficient ways of communicating
and we capture much less. Note that in both cases the 'process' is
followed. Here at Pearson that is a requirement: we are a CMM level 4
organization so we do the process. The difference is that Eclipse
developers want to use Bugzilla and they use it to manage daily work,
whereas with TeamTrack we use it when we have to.
Besides the performance issue such things as the ease with which one
issue is linked to another (in Bugzilla this happens automatically when
a user refers to bug 123 in a description field), or organized in
dependency relationships, or referred to in a URL, or found in query,
all contribute to a much more usable and productive system. These, I
contend, wind up contributing more value in terms of traceability and
process control than customized workflows because they promote tool use
by a surprisingly significant factor. Water flows to the lowest point,
even if it is only a little lower. One can redirect a torrent with a
very little well-chosen digging.
> I have looked at ExtraView and I was equally impressed with their
> "vision" but it doesn't really look that different from TeamTrack in
No, but the implementation is different. ExtraView appears scale much
better and has much more capability for integration and customization.
Several folks at ExtraView came from TeamTrack and they'll testify to this.
Furthermore, the companies are different. The acquisitions which
TeamTrack has been through have not been good for the development of the
product--nor, I believe, for its customers.
> It's not clear this is an issue with either product but
> simply with the implementations.
It may not be an issue with the 'philosophy' behind the product, but the
products themselves are implemented and those differing implementations
(even when the differences are subtle) have dramatic consequences
despite an organization's careful configuration of the system.
What I learned in being responsible for the selection of PEM's SCM tool
(Perforce) is that the devil is in the details. Considerations which
never make it onto a feature list wind up being the most impactive and
Pearson Educational Measurement
2510 North Dodge St.
Iowa City, IA 52245
john-mason.shackelford at pearson.com
More information about the perforce-user