TFS vs. OSS - Round 4

time to read 10 min | 1869 words

Aha, my dear colleague. Yet you continue to use Visual Studio .NET, which, even without team system, has it's share of usability problems for you, I'm Sure. Why not use notepad or eclipse for writing the code, then running a command line to compile it, then use an XML Editor to change the config files? Why are you using a suite of integrated tools to develop code, in an environment which you probably aren't that crazy over?

Seeing the bigger picture perhaps? There is some value to it after all.

I actually do quite a bit of development using Notepad :-). I am not using Eclipse because I was never able to really grok it, I am afraid. A simple case of being lazy about it, I admit. I don't think that I ever said that there isn't a big value in an integrated environment. You won't find me running for kdbg to debug my CLR program (Ahem, yes, I was talking to that shady guy, right over there, not debugging the kernel to find ArgumentException).

I think that it is safe to say that it is public knowledge that I am not crazy in love in VS (maybe crazy because of it). There are two reasons that I use it over Notepad / #Develop / Eclipse. It has an excellent debugger, and I get ReSharper. Oh, and I am willing to degrade the debugger experiance. There is a reason why I would like a JetBrains IDE so much.

I should also point out that for a very long time, I developped in Boo, which entailed working in Notepad2, with Python syntax colors, compiling via NAnt and debugging with CLR Debug. Boo's syntax made it possible, and I worked on small enough projects that allowed me to live without R#.

And don't get me started on the "zone" thing. You develop on a windows machine, right? your "zone" gets disrupted a million times a day by tiny little operating system mishaps, dialogs, crashes and what not, yet you continue to use it and not another operating system. I guess sometimes you compromise to get what you need.

And how about working with people? People sometimes take me out of the "zone", and cellphones too. Gosh, I should just program in a cave with a rock and a wall in front of me. Oh, wait, there are advantages to doing the opposite.

While taming Windows is not a task for the faint at heart, I do believe that I have managed to do so. My system doesn't interrupt me, and if I want to do a bit of serious coding, I close outlook, phone and messenger, growls at anything that comes near, and work. That cave sound charming, I would need a whiteboard and someone to ping ideas from, though.

Did I really paint myself as a binary guy? "My way or none"?  I hope not.

About the people comment, I can get quite a bit done when I am working alone, but it is much more fun to work with other people.

Resharper has it's slow moments inside VS.NET. It sometimes makes you aware that it is working. Yet I still use it. Sum is great than thee parts etc..

There is a big difference here, actually. ReSharper almost never does anything unles I tell it to. If it takes time to refactor, or search for a reference, etc, that is okay, I just told it to do so. The problem with TFS taking me out of the zone is that it surprises me, and not in a good way.

Roy makes an excellent point when he asks who this is good for:

I'm wondering if the word "I" is to blame here. Yes, for you you get all that you want, while still paying the price of configuration, forking, patching, learning curve etc. What about "us"? Would it be just as easy for an entire team or an full dev group to do such a move? Assuming that this magical suite of OSS tools that provide exactly what you could get in TFS exists (yes, I'm sure you can make it happen, Oren), what is the cost of:

  • Learning that you can actually do something like this without having an OSS guru in the house? (Solution Discoverability)
  • Writing the documentation of how you did it and keeping it all as one big happy maintainable system?

Again,  not for you personally, but for an organization?

Let us put the forking/ patching out of the loop please. I don't do that, and it muddy the waters with irrelevant stuff. And configuration / learning curve exists for TFS as well, I would say.

Roy, I assume that when you do a TFS project, you rarely gets to go in, install it, and go home. Usually there is customization that needs to be done, to make it work the way that organization works. There is configuration, there is training an admin that can watch for it, there is documenting what you did and how / why it was done, etc. That one is not different for any stack that you choose.

For discoverability, that is another matter. Assuming that I am in the market for a new development environment, that is a big desicion, and I need to make an informed one, so I would look at what I need, and then see what set of tools would give me the best solution. It has long been heralded as the unix tradition, but collaboration of focused tools is often greater than the sum of its parts.  The integrated solution is tempting indeed. But most people have learned that integrated solutions often carry their own set of problem and would evaluate separate solutions working together as well.

Would it be easy for the entire team? Yes, I believe so. You would need to teach them what is the way that it is going to work, which you need to do anyway, and off they go. I didn't find any of the tools that I have mentioned to be of high maintaince, zero friction, again. And here I am talking not about me, I am talking about team memebers that doesn't have my experiance in working with those tools.

I am certainly not seeing any issues in my organization, and as I mentioned, my time troubleshooting those tools in the last 6 months was ~15 minutes. And they are certainly in active usage.

TFS may not be your thing, but it sure as hell saves lots of time for lots of people who learn to work with what they have and optimize it, extend it, and not go and work on something that may be the "perfect" thing for them, but less perfect for other people. If you plan on saying "just say no" you should at least know that people might find out that what they turned down actually has more value than the little things that annoy you.

I am not "just saying no", I have made multiply attempts to use TFS, in all cases, I have run into those issue which were unacceptable to me and my team. I am not saying that TFS is worthless, or that it doesn't bring value. I am saying that in the grand scheme of thing, I have found that TFS has issues that prevent me and my team from using its core functionality. And that without the SCM integration, I don't see the value in TFS over other tools.  I also think that you are underestimating how big those "little things" are.

I have seen people that works with it that accept those flaws as given. If they can manage that, fine, and I hope that they will leverage TFS to its full potential. That is not the way I feel, and from the attempts that we made, we found that after getting used to zero friction tools, tolerating friction gets very annoying, very fast.

When you aim wide, you have to aim a little lower. I think that's just the way it is.

And I disagree with this completely. You have different set of concerns when you aim wide, but that doesn't mean that you have to aim lower. That may work as long as there isn't a competitor that aims wide, but keep better quality. I think the Japanese proved that with their cars thirty years ago.

I may sound a bit harsh, but this is all in a good mood. I respect and like Oren very much, and much beer will be had together at DevTeach next month!

I am not my code, not am I my opinons, I can enjoy a good debate even if at the end I won't "convert" you to my way of thinking. Frankly, I don't even expect it. The fun is in the debate itself...