[p4] Large development defect management (was: P4 with BugZilla, TeamTrack or ????)
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
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
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?
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
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
Pearson Educational Measurement
2510 North Dodge St.
Iowa City, IA 52245
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