5 messages in com.perforce.perforce-user[p4] Large development defect managem...| From | Sent On | Attachments |
|---|---|---|
| Smith, Jeff | 18 Mar 2005 07:55 | |
| John-Mason P. Shackelford | 18 Mar 2005 14:07 | |
| Smith, Jeff | 24 Mar 2005 06:35 | |
| John-Mason P. Shackelford | 24 Mar 2005 09:20 | |
| Smith, Jeff | 25 Mar 2005 06:59 |
| Subject: | [p4] Large development defect management (was: P4 with BugZilla, TeamTrack or ????) |
|---|---|
| From: | Smith, Jeff (jsm...@medplus.com) |
| Date: | 03/25/2005 06:59:42 AM |
| List: | com.perforce.perforce-user |
John,
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?
Jeff
-----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 ????)
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/
_______________________________________________ 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 http://maillist.perforce.com/mailman/listinfo/perforce-user