[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


Jeff,

 > 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
 > philosophy.

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 
important.


John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford at pearson.com
http://www.pearson.com/






More information about the perforce-user mailing list