Elevating our Tools

Why is it some people out there feel the need to elevate technology and software tools to the status of religion? This is something I've never understood and don't think I ever will.

Prime example: This post on the MS Windows Home Server blog innocently directs readers to a guide on how to use a WHS add-in to publish an ASP.NET website. Take a moment to note the name of the blog, MS Windows Home Server. By this name, I think it's safe to assume the blog is about a Microsoft product of the Windows family.

The post is three lines and a link to the guide. Below it are pages and pages of responses about why ASP.NET sucks and PHP is capital-g God. I kid you not. These people must subscribe to the RSS feeds of as many blogs as can be imagined, just waiting for some mention of Microsoft products or technologies to pounce on and preach its inferiority to us unwashed masses, and educate us about how superior their technologies are (and by theirs, I mean the ones they use but likely had no direct involvement in creating or building).

This is pretty much what this technological evangelism looks like, because make no mistake, in the final analysis they're preaching about the tools they use:

“My hammer is better than your hammer!”
“No, mine is better because it works better than yours.”
“Well, your hammer was made by HammerHard, a huge conglomerate corporation for the purpose of making money and locking you into their monopoly on nails and wood. Mine is made by HPH, which is built by hardworking volunteers, therefore it’s less evil.”
“Yeah, but your hammer sometimes misses the nail, and doesn’t have a claw for removing nails.”
"Bob Vila uses this same kind of hammer as me. You're just a fanboy of HammerHard.”

Pathetic.

Here's an idea: Instead of arguing the superiority/inferiority of tools to an audience that really couldn't care less, apply this simple checklist to the tools you personally choose to use:

1. Is it easy for me to learn?
2. Is it easy for me to use?
3. Does it do what I need it to do?
4. Am I comfortable with it?

If yes to all, then continue using your tool, and shut up. You can't convert people who are comfortable with their tools by telling them how comfortable you are with yours. You can debate it until you're blue in the face, but at the end of the day, you haven't changed the heart or mind of a single person.

Now, go outside, take a walk in the park, and enjoy the weather. Because there's far more important things in life than hammers and web application frameworks, let alone preaching about them.

Repeat After Me...

...If I circumvent the way a system is designed to work, it's my own fault when it doesn't work as designed.

It amazes me how many people who design and build software don't actually seem to understand this concept.

A little background: Team Foundation Server source control uses "workspaces" to manage version-controlled fies locally. A workspace maps the source control folder structure and files with local copies on a one-to-one basis. TFS keeps track of what version of each file you have locally; the local files are all marked as read-only (using the file system flag) until they are checked out for editing. This prevents accidental edits and overwrites when the file is not actually checked out for editing. TFS cannot track changes made to the file if it is not checked out first.

This was explained in plain and clear detail when we migrated to TFS: Do not modify source-controlled files without going trough the source control system.

Recently, a couple of developers have argued with me that when they "get latest" from TFS on particular files, they aren't always actually getting the latest version. Suspicious, I began asking questions, and after a very short time the problem was revealed. These developers have been manually browsing to their local workspace files, unchecking the "read-only" flag, and making changes to source-controlled files, effectively circumventing the source control process.

Of course, after making these "unseen" edits, they expect that "get latest" will replace their modified copy with the latest version. The problem is that if TFS already thinks that they have the latest copy (remember that it keeps track of this), it will not try to get it again, satisfied that you're already set up with the version you want.

And somehow, despite being told not to do it for this very reason, they did so anyway, ...and then proceeded to justify their reasons for doing so, and blamed TFS for not working properly.

Well, DUH.

If you circumvent the way a system is designed to work, don't expect it to work as designed.