Zealotry For Good And Evil

March 10th, 2009

Brent Simmons makes some great points in his essay on the role of zealots in the software industry. I especially relate to his observation that zeal, or the mere impression of it, can repel somebody from what might otherwise be an attractive technology.

In particular, Brent confesses that before he could even try the popular git source control management tool, he had to overcome his resistance to joining rank with some of the cult-like followers of Linus Torvalds, the famous developer of git who also created the world-changing Linux operating system.

After giving git a fair shot, Brent decided it was not for him. What eventually got to him was the usability, or lack thereof, of the system. The pesky little details really added up and ultimately made him feel that the tool was costing him more effort than it was saving.

Sounds like a Mac user to me.

Zealots are useful to society because of and in spite of their tunnel vision. When you find somebody who believes so strongly in something that they need to shout it from the rooftops, you can be damned sure something’s about to get done. The problem is that even if you don’t agree with what they’re shouting, you’ll have to stomach their success, unless you care enough to stop them.

From the Oxford English Dictionary definition of “zealot”:

One who pursues his object with passionate ardour; usually in disparaging sense, one who is carried away by excess of zeal; an immoderate partisan, a fanatical enthusiast.

It sort of reads like those contrived job interview responses to “what is your greatest weakness?” That is, a zealot is a deplorable person who you would very much like to have on your side.

We’ve all benefited from zealots who were on our side, and all suffered from those who were not. The famous zealotry of Steve Jobs, which Brent also alludes to, is at least partly responsible for the iPhones, iPods, and Macs that many of us love so dearly.

As for git itself, I’m inclined to agree with Brent. The technical advantages of this tool are because the people who pursued it did so with a great zeal for things that mattered to them. In my opinion, usability and a consistent interface were not among those things.

Now it’s up to somebody with a dissimilar zeal for source control to show us how it’s done. If git is the metaphorical Xerox STAR, how will you turn it into a Mac?

10 Responses to “Zealotry For Good And Evil”

  1. Jon Gretar Borgthorsson Says:

    You should also check out GitX(http://gitx.frim.nl/). A very nice OS-X GUI for git usage.

    Brent’s experience seems to be in single developer project. And yes then there is this extra step of pushing the changes to the server after a long day of coding. But I feel the advantage of having actual branches gives me back that time quickly. However as soon as you have 2 developers on a project then git starts being easyer. And in a large open source project with 10 active developers and tons of patch committers then I couldn’t imagine using Subversion. Git simply wins in that scenario no matter which way you look at it.

    I really didn’t like Git to begin with. Mostly because I saw Linus talk about it and he is a great bit dick when he talks about things. :) But after downloading a few screencasts I was sold.

  2. charles Says:

    Eric Sink actually has a series of 2 posts about other aspects of git vs svn, see http://www.ericsink.com/entries/dvcs_dag_1.html

  3. foljs Says:

    What eventually got to him was the usability, or lack thereof, of the system.

    Compared to what?

    I mean, Git is so far ahead of SVN feature and usability use that it’s not even funny.

    Although it’s not ahead usability wise in the sense that it’s meticulously designed but in the sense “Hey, I don’t have to jump through 100 hoops to do this thing that should be simple”.

    We could do with Xcode integration and/or a nice GUI though (GitX is still not there).

  4. Eric Says:

    I haven’t tried it yet, but there’s easy git (eg), which aims to provide a simpler interface to the underlying functionality. There are some other wrappers along this line of thinking.

  5. George Sudarkoff Says:

    I’ve two points. (1) I’m pretty sure that Xcode integration will deliver Mac developers to git in droves zealotry notwithstanding. (2) Usability of any Unix-style CLI utility is in its superb fit for automation. It’s foolish (to put it mildly) to complain about poor usability of awk, for example.

  6. arw Says:

    Long time Mac users such as myself have little tolerance for software having a poor user interface, i.e. anything made by Microsoft. This comes about not from zealotry, but rather years of working with software elegantly designed to foster a rich user experience. Most software written for the PC simply would fail if written for the Mac simply due to a poorly designed, often complex user interface—Mac users demand otherwise. That being said, it’s really difficult to present complex functionality in an elegant way, simple enough to get the job done without losing power and flexibility.

  7. Steve Madsen Says:

    I’m always suspicious of anything I hear the “cool kids” are using. Git is no different than many other things that fall into this group. It’s good, if not great, for the things it was designed to do, but I can’t say for sure because I (and, I’ll venture, most people) don’t need to do those things.

    For me, Subversion fits the definition of how source control works. I had used CVS and similar systems for years. I don’t want to spend my time worrying about whether or not my project history is perfect. If I can tag, branch, merge and get my code in and out, and the stuff I do every day is easy and fast, that’s good enough. Git does lots of whizzy things, but they’re mostly things I don’t _need_ to do.

    Git has one feature I like: it’s nice to keep everything in one directory, repository and all, for short-term client projects that don’t otherwise use source control. In these cases, it’s nice to have a safety net, and just as nice when the project is complete to archive or delete that one directory. I don’t want to clutter up an existing Subversion repository with these projects, nor do I want to spend the time to create dozens of short-lived repositories.

  8. DDA Says:

    One problem with joining the zealots is that you get affected by any backlash against said zealots; the amount of “I’m not with those guys” one has to do can get tiresome.

    Note also that there are many times when a zealot getting things done isn’t a good thing; “if it ain’t broke, don’t fix it” applies to a lot of what zealots want to fix.

    I also believe that Brett could solve his issues with Subversion by enabling https access to his desktop repository; at the end of the coding day on the laptop, he just commits to that and he’s done.

  9. warren Says:

    There’s no reason that two sequential common applications like commit and push could not be put into a single batch file. “checkin.sh”


  10. Marc Charbonneau Says:

    It’s funny, my experience as a single developer is pretty much completely the opposite. I wanted a version control system where I didn’t have to use a client-server model, and didn’t have all the drawbacks of SVN such as renaming. Git turned out to be more “mac like” from my point of view, even though I never really touch the advanced features.

    In defense of Subversion, this was before all these awesome looking graphical SVN clients came out, and also before it had Xcode integration. With Github though I’m still very happy with git, I can’t see myself switching back to Subversion any time soon.

Comments are closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.