The Joel on Software Discussion Group

It's great that Fogbugz plans to add version control support and that's probably the best thing for 4 of 5 of Joel's 5 worlds

http://www.joelonsoftware.com/articles/FiveWorlds.html

But Mercurial sucks for the last one, games. We need to manage terabytes of binary data. Our teams are less than 25% software engineers. Instead our teams are full of artists making terabytes of assets.

In order not to step on each other toes the artists actually need a version control system that LOCKS the files when one artist is editing because changes can not be merged so, unlike a software engineer, an artist needs to know that no one else is working on the same file.

Here's hoping fogbugz can be made to support perforce (fast) and/or subversion (cheap), both of which support both an edit/merge/commit model (good for software) AND a lock/edit/submit model (good for assets)  vs mercurial which only supports the format because of its distributed nature.

When talking about games, the main differentiator that he came up with was the Quality requirements of embedded software combined with the hit vs failure business model.  I'd argue that Shrinkwrap and Embedded have the same economics issues. That kind of leaves Games out in the cold. 

I would say there is a legitimate 5th world there, but not for the same reasons.  Instead, I'll call this world "Epic" software: projects so large that thousands of people are potentially working on them.  Large, mass market 3D games still fall into this category.  But now so do things like operating systems and database engines.  Some common factors they share is a mix of very high-level (user interface) programming, very low level (performance critical, written in assembler) programming, and support work (more graphic design, armies of testers, projects managers, etc). 

I bring this up because I think in this case you can separate out the graphic designers into the 'support' role.  I'll use that term loosely, because you could just as well say the programmers support the graphic design team. The important thing is that you don't necessarily want them using the same tools the programmers do.  And even if you do, you could also argue that they still fall outside of FogCreek's core mission.

I would argue that one of the worlds that Joel mentions - throwaway - is naturally not something that benefits a lot from version control or bug-tracking or any of that. For example, if I write on the command line a small regexp search command to search among files of different types. For example this command: (taken out of my Bash history)

<<<<<<
grep -i closed-books FreeNode-*
>>>>>>

This short grep command will take much more time and be much more verbose in ANSI C. But I'm not even going to put it in a file, because typing it on the command line directly will be faster for me. There are even shorter commands in my arsenal : "ls", "cd $this", etc. - all of them throwaway.

Nevertheless, throwaway code is very important - it's hard for me to estimate how much throwaway code is written every day, but it's probably a very significant volume. It's like a large amount of the speech in the world is stuff like "Hi!", "Good morning.", "Do you want tea?" or "I'll have the cheeseburger." which is throwaway and never recorded. I think part of the reason many languages and technologies languish is because they have not been made suitable for throwaway code, and other "quick and dirty hacks". For reference, see:

* http://www.perl.com/pub/a/2007/12/06/soto-11.html

* http://www.paulgraham.com/popular.html (see "5 Throwaway" there).

I should note that I once had plans of creating a very enhanced version of GNU readline called "eatline" with many nice philosophical enhancements including a pluggable database backend. I was demotivated a little after I discovered that there was already NetBSD's "editline" which was under a BSD-style licence and also an X11L replacement (though its scope was much smaller than eatline's scope)

Moreover, I recently started using version control for my shell's history file
(Subversion in my case) but that was as part of a cron script that backs it up because it sometimes gets truncated from some reason.

Regards,

-- Shlomi Fish