+972 52-548-6969
Integrated Tools vs. Collaborating Tools
Daddy Starr has reponded to the latest discussion on TFS vs a mixture of tools, he points out that something that was missing from the discussion is...
This misses the entire point of a common development platform, which is a far more important value proposition than a feature set within a subsystem. The ability to repeatedly drive software through to delivery using common standards of quality, completeness, performance, trace-ability, and transparency is invaluable to any organization.
Do you really think you can get all of that from cobbling together loosely coupled open source components? Having been there and done that, I say, “No way.”
I agree with the first point, but disagree with the second. I can get this from a a set of components that I assemble together. It is not trivial, but it is not very hard either, and it is something that you need to do anyway.
Agreed, the discussion was being side tracked because I use OSS tools and gave examples from them, but I was mostly talking about the general idea of separate tools that collaborate for a cohesive whole.
The one thing about Team System that is met with the most doubt is the idea that the system is genuinely open. [...] For example, we already know that we can use CruiseControl.Net to run the builds instead of TFS build types. We can use NUnit as the unit test framework instead of MSUnit.
And didn't you just lose the integrated benefits? Yes, I am aware that you can use CC.Net to work against TFS, and you can use NUnit to run tests, etc. But those aren't integrated into the product, you need to "cobble together" a solution that would give their output back into the system. How do you track build results now? How do you go from a build to the change set that triggered it?
The part that I seem to fail to explain is that I have looked at TFS, saw that it had major failings in Unit Testing, Continious Integration and Source Control, once I saw that, I was no longer interested in the integrated package. And if I am not interested in the integrated package, what does TFS has to offer me? Not much that I can't get from somewhere else, frankly.
Remind me not to mention the Vi vs. Emacs discussion, then :-)
Comments
LOL. You got me on a few there :).
I feel my team has leaked money debating these issues of tools and process. I have seen so much time spent on the debate of red widgets vs. blue widgets that I think we can forget the real reason why we are all here: Shipping high quality product with spectacular new features.
Frankly, I stand on the point that TFS and VSTS is a great bargain and is not free like a puppy. Further, I admit that Team System is v1.0 software. I gotta tell you, MS really hit a triple on this product. Maybe not a home run, but that can come on rev 2. They definately hit a triple thoug.
With that in mind, I am anxious to simply use the tools to their fullest capacity, not spend a lot of money on system maintainance and configuration (OSS) and get our products shipped.
Emacs rules, BTW.
I do too, that is why I am using the toolset that I do, because I don't want to deal with babysitting TFS.
I config it once, and then forget it, literally.
That is a non issue to me, since I am not the one paying for the thing :-) I am more concern on its usage.
VI versus EMACS arguments are pointless and a waste of time.
VI is the best.
So what do you like to use for defect tracking?
Trac, right now.
Comment preview