Unit Testing, Agile Development, Leadership & .NET - By Roy Osherove
Very well said Roy! I agreed with you on most of the points.
In general this entire issue seems to me like a conceptual re-hash of the age-old 'single swiss-army-knife toolset that tries to be all things to all people' vs. the 'best-of-breed' approach to creating a toolset for yourself.
All the age-old issues come to the fore both in favor of and against the single monolithic solution (pos=high level of integration between the tools, neg=likley not the best available for any ONE thing it does).
And all the same familiar issues are present in re: the 'best-of-breed' tool selection paradigm too (pos=flexibility to pick best tool for the job, neg=steeper learning curve due to dissimilar interfaces, integration challenges vary by tool, etc.)
In some ways, this is the same argument that ensued when MS Office was originally released with what any objective person would have to agree were pretty anemic wordprocessing and spreadsheet apps that paled compared to what WordPerfect and Lotus-123 offered at the time. But if one attempted to embed a 123 spreadsheet in a WordPerfect document, heaven help you (and I was one brave soul who attempted this under WFW3.11). And so, until doing such a thing became a more mainstream need, most existing users of WordPerfect and 123 stayed with those solutions until the need to cross-integrate content from one to the next became greater than the need for any one specific function or feature offered by the separate tools.
I think (at least at this point in the VSTS release cycle) any objective person would be similarly hard-pressed to argue that just about any SINGLE tool offered by VSTS is even as good as (never mind better than) what is already available in one or more mature stand-alone tools (either opensource OR commercial 3rd-party).
As someone who came to the development world long before even VS (and thus certainly long before VSTS), I tend to prefer the 'assemble your own tools' approach and accept the 'penalty' of my having to do the integration to get the tools to play nice together so that I can have the freedom of choice in my tools, but I readlily admit that's a personal preference; I have chosen one over the other and have accepted both the positives and the negatives of my choices.
I'm certainly not suggesting that the day won't come when I'll need to somehow accomplish the software-development equivalent of trying to embed a Lotus-123 spreadsheet into my WordPerfect document, but until that day comes (for me) I will remain firmly in my present camp.
If anyone's interested, my toolset largely consists of the following collection of things that likley aren't that different from what others have selected too...
-SourceGear Vault for source control
-NAnt for build control
-NUnit for unit testing
-Rhino Mocks for Mock objects
-NDBUnit for data-dependent unit testing (how else does one test one's DAL?)
-CruiseControl.NET for a CI environment
-NCover for test coverage reports
-NDepend
-NDoc for XML comment -> code doc formats (ok, so I'm giving up on this and moving to SandCastle like everyone else, but I'm NOT happy about it :)
I, too, am absolutely pragmatic when it comes to the tools I use. I'm not drawn to tools because they're open source or closed - the criteria you've given are the ones which everything is judged by, but I think you're showing a little unfair negativity towards (some) open source tools, so I had to leap to their defence.
The open source tools I use for .NET are (at least) Subversion, TortoiseSVN, NUnit and NAnt.
"as hard if not harder to maintain a full range of open source tools"
I haven't tried TFS, but I also don't have a problem maintaining the above tools. I don't mind having to go to separate web sites to download them as this isn't something I do very often. Sometimes I install from copies I already have, as I have no desire to see if there's a newer version.
"documentation"
The documentation for all of the above is decent enough - I certainly haven't had much trouble getting them all working. For NUnit and NAnt, I followed the examples of others, found on websites/blogs, but have had to refer to the NAnt docs a few times to help me sort out building some VB6 code.
Examples of great documentation are the TortoiseSVN integrated help and the Subversion book - which is free in HTML form and you can also buy on paper.
"support services (if at all)"
When I had questions about doing slightly unusual things with Subversion (on the server end), I joined the #svn IRC channel on FreeNode and the helpful people there were glad to answer my questions - or point me to the relevant documentation.
"it is harder to get up to speed on an open source product than a commercial one (there are always exceptions)"
This entirely depends on the product. I haven't noticed either being better in general. I've had very good (TortoiseSVN/ASP.NET) and very bad (Ruby on Rails/MSI) experiences with getting into unfamiliar products.
"Ease of use"
Do you have any examples?
"If you found subversion to be working too slow [...]"
Indeed, if svn had problems, I wouldn't enjoy fixing it (it's not written in VB.NET, C# or Ruby, and I've forgotten everything else ;) but I'm pretty confident that I'd be able to get a fix for any real problem within hours - and for that fix to be in the next release of svn.
If I find a problem in a closed source product, I'm completely at the mercy of the person or group behind it. If they decide my issue is important (and not 'by design') then they might get around to fixing it in several months - or just promise it won't be an issue in the next major release, which might be in a few years.
I know this isn't true for all closed source products, but neither is it necessarily true to say that it's harder to get fixes for open source projects.
Lastly: Some of the closed source development tools I use day-to-day: VS.NET, VisualSVN, ReSharper, NCover, ViEmu.
@Stephan,
The way I understand history, Excel and Word took the market by storm because their competitors were stupid.
Lotus 123 spent a lot of time re-writing their code, and the Word competitors didn't have a Windows version until very late in the game.
Also, can you think about the killer "embed excel in word" feature for TFS?
My bosses loved the open source source/control and bug tracking software because everything was displayed in "Table/Spreadsheet" views.
They're all old ENgineers. The developers were cryinging for TFS for months while it was in beta, heck we were even throwing tantrums, and we finally got our way mwhaha.
However, once we got TFS a few of the managers and directors hated it because looking at the Work Items was too hard for them. Until we showed them the Export to Excel... then we had to teach them... ignore that... then we had to write their queries for them.
But, once all that was done, they loved TFS. THere are many featuers of TFS that we can now not live wihout. The main one is the ability to check in code, and have it linked to bugs in the same system.
When MS Excel first came out, it sucked compared to Lotus 123. MS has always used the Speed to Market Strategy for new products. THey got Excel out, and then they improved on it. Eventually, it was better than Lotus 123.
suprised to see subversion poll so well. i thought of it more as an 'up and comer' than a 'most popular' winner.
That's because subversion just works. The thing I don't like with TFS is that I cant use it with my old VS 2003 projects.
The thing putting me off TFS is the extortionately high pricing.
Team Edition for Software Developers - new installation... $5,469 for first year, $2,229 for subsequent.
Visual Studio Pro Edition is a $799 one-off.
Sure Subversion, AnkhSVN, Trac, NUnit etc. aren't well integrated but over a 3 year period you're paying nearly $10,000 PER DEVELOPER for integration.
Sure there are other benefits for being with the MSDN subscription it comes bundled with but not enough to justify $50,000 over the next 3 years for a small 5-man team.
[)amien
At our company, we have a full open source pipeline:
- Subversion
- TortoiseSVN
- AnkhSVN
- NAnt
- NDoc
- MbUnit
- Doubler
- NCover
- CruiseControl.NET
- Trac
It took some time to make it all work but we don't regret it. When a bug is found, the fix comes out way faster than with commercial products.
I have nothing against Microsoft. I love .NET and Visual Studio. I just think that open source is ahead of them on other tools...
Pingback from Jay R. Wren - lazy dawg evarlast » Blog Archive » TFS woes
Pingback from Interesting finding - 04/30/2007 « Breaking the bottleneck…