[p4] Large development defect management (was: P4 with BugZilla, TeamTrack or ????)

Smith, Jeff jsmith at medplus.com
Fri Mar 25 07:00:04 PST 2005


You bring up some good points although that's not what I was discussing.
I was simply addressing the first issue with selecting a CM tool:

- Can the tool meet the implimentation requirements.

I fully agree that this is not the only question that has to be
answered.  Specifically, the one you indicate is equally as important:

- Does the tool perform as designed and will it scale approriately in
your environment.

Both of these questions are very important but most technical people pay
less attention to the first than they should.  The tool selection
process should be approached like any software project.  This includes
up-front use-case driven requirements.  Only once you have those, you
can look at the possible tools and see if they will meet your needs.

I've seen too many development groups that select a tool simply by
seeing how it is used in other organizations and ignoring the political
and cultural distinctions that will prevent it from being used in the
same way.  There are simply no one-size-fits-all solutions in SCM.  What
you may find as attractive features in Bugzilla may actually turn out to
be negatives for some other development group.  

To your specific comments about TeamTrack, I would be interested in
hearing about your implimentation platform.  You refer to "big iron" but
I would like to know

TeamTrack Version?
Webserver and version?
Webserver OS Version?
Backend DB and version?
DB OS Version?
How are the services split between which systems and how are those
systems configured for processors and memory.

We will be doing load testing but it would be nice to hear about your
configuration so that we can have a heads-up with respect to the
hardware we plan to use.

Finally, has Serena support been contacted about your performance issues
and what was their response?


-----Original Message-----
From: John-Mason P. Shackelford [mailto:john-mason at shackelford.org] 
Sent: Thursday, March 24, 2005 12:20 PM
To: perforce-user at perforce.com
Subject: Re: [p4] Large development defect management (was: P4 with
BugZilla, TeamTrack or ????)


 > 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

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 

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

Come to the 2005 Perforce User Conference, April 14 & 15 in Las Vegas.
Learn more: http://www.perforce.com/conf 

perforce-user mailing list  -  perforce-user at perforce.com

More information about the perforce-user mailing list