--- title: "What build tool do you use? And TFS Vs. Open Source Round 3" url: "https://osherove.com/blog/2007/4/29/what-build-tool-do-you-use-and-tfs-vs-open-source-round-3.md" canonical: "https://osherove.com/blog/2007/4/29/what-build-tool-do-you-use-and-tfs-vs-open-source-round-3.html" published: "2007-04-29T14:34:34" updated: "2007-04-29T14:34:34" tags: ["General Software Devel..."] author: "Roy Osherove" description: "Embedded Flash media from the original post is no longer playable. Ah, Oren. You amuse me yet again , you OSS guru you ;) (he replied about my earlier post regarding using TFS Vs. Open source tools) (No I don't have…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # What build tool do you use? And TFS Vs. Open Source Round 3 By Roy Osherove April 29, 2007 In [General Software Devel...](https://osherove.com/blog/category/general-software-devel) **Historical article** · Originally published April 29, 2007; technical details may be outdated.

Embedded Flash media from the original post is no longer playable.

Ah, Oren. You amuse me yet again, you OSS guru you ;) (he replied about my earlier post regarding using TFS Vs. Open source tools)

(No I don't have shares in Microsoft)

(I also do consulting on TFS)

(I also do Consulting for Configuration management using open source and commercial tools, many times connecting tools from both worlds together)

Oren:

"Let me put it in the simplest terms that I can, TFS puts me out of the zone. That is simply unacceptable, period. If I need to be aware of "Don't go near the Team Explorer Tab, it will hung VS for 5 seconds", I am not in the zone. If I am not in the zone, I rarely get to code well"

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.

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. 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.. Oren said: > "And it is another story yet again when to say, "I know a different solution, which can give me all that I need/want, so I don't have to _deal_ with those shortcoming." The bigger picture as I see it is that I get everything that I want, and don't have to waste my time on patching holes in the tools that I use. Tools should be transperant, not road blocks" 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? My main point is that, yes, both systems, the closed one and the open one, need care and attention. At the end of the day, it is the system that can last longer in the real world, which is discoverable, supported and more usable, that will gain more popularity. That's the same percentage you see with Windows and Linux adoption,  That's the reason Mock Object frameworks are still considered somewhat of a "black magic" for lots of people still. that's why Castle and Active Record are still now as well known as the documented and commercial ORM tools out there (and they are considered to be top notch when it comes to documentation) 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. **When you aim wide, you have to aim a little lower. I think that's just the way it is.** Smaller or one men shops may find it easier to use open source tools. larger ones usually still aim for something with a little more support. (Linux is not an example because it has also turned into a money-making model and so gets support, updates, documentation, consulting etc..) I'm not ashamed to say that I've used VSS and still use it today in some cases, along with svn, and I still find VSS' experience to be better in terms of usability .Yeah, it's kind of a crappy product in many ways, but the bar is so low it's just easy to work with and integrated everywhere (yes, so does svn... I know I know) So, am I a heretic who should be shot because I tend to flow into the path of least resistance? You are doing the same thing, only you are looking at a **different kind of resistance**. Adoption resistance is just as important. _( 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](http://weblogs.asp.net/rosherove/archive/2007/04/27/see-you-at-the-devteach-agile-track.aspx)_ _next month!)_ ## More in General Software Devel... [All posts in General Software Devel...](https://osherove.com/blog/category/general-software-devel) - May 16, 2007 ### [Learning new technologies: Is C# a XAML for the CLR?](https://osherove.com/blog/2007/5/16/learning-new-technologies-is-c-a-xaml-for-the-clr.html) - May 3, 2007 ### [Tips for a successful team lead](https://osherove.com/blog/2007/5/3/tips-for-a-successful-team-lead.html) - Apr 29, 2007 ### [What Source Control tool do you use? And more on TFS Vs. Open Source tools](https://osherove.com/blog/2007/4/29/what-source-control-tool-do-you-use-and-more-on-tfs-vs-open.html) - Apr 29, 2007 ### [TFS or not? Being a perfectionist in a realistic world](https://osherove.com/blog/2007/4/29/tfs-or-not-being-a-perfectionist-in-a-realistic-world.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/