I’ve had this comic kicking around for a bit. From left to right is Daniel, Nicholas, and myself.
Click the image for the full comic.
All done? Okay:
The particular issue behind this comic is an ongoing matter of what versioning software to use, and behind that, how to choose what tools to use to coordinate work, and behind that, what makes which tools best for collaborative development. This is a bit of a mess of a question that I’ll wade through with the power of anecdote rather than some kind of comprehensive answer.
(I should add here that I am aware that Git has a mac version with a GUI. Please feel free not to send me any more helpful messages.)
With Nicholas and Daniel off on some remote island in the Pacific, myself in a lovely northwest metropolis, and Derek in some dark place south of the border, we need software that harnesses the full power of The Internet to effectively work together. For communication we use some combination of IMs, Google Wave and Docs, a dusty wiki, email, and occasional face-to-face meetings when schedules permit. For project files we’re presently using SVN and there has been talk of moving to Git, as evidenced by the above comic.
Now the point of the original disagreement which led to the comic is that I’m an artist; While I do know some coding and technical tricks, I hate the idea of having to learn to deal with a new command line interface for versioning software (or whatever it may be). I have plenty of work to do already and would like to avoid major investments of effort unrelated to my specialization in the whole enterprise. And this is to say nothing of what might happen when we bring more, less techy artists in on Gaslamp projects. Of course, as established, Git does have a GUI for my ilk. But there will be other software used in our future projects and I think that usability issues may arise, especially as we run a zero-capital startup and end up using a lot of open source software or homebrewed tools.
Teaching a particular command-line interface to an otherwise uninitiated artsy type takes important development time away from all parties. There is a balance to be found between finding/developing tools that make the work of the development team easier and the act of development itself. I saw just such an argument made for in-house tool development (down a few paragraphs) by Eskil Steenberg, the one-man team creator of Love. On the other hand, if I recall an off-hand comment correctly, Nicholas expressed skepticism at the viability of Eskil’s approach to tool development — just as it might turn out to be efficient to create one’s own 3d modeling suite, it might just as well turn out to be a tool too hopelessly personal to be useful to anyone but the maker.
(And I haven’t even started on our appalling sprite format that’s created a content pipeline through some ancient graphics software which causes me existential pain. Sacrifices have to be made for the team, of course, so I weather this. For the team!)
Balance in all things, and most important from my perspective: choose tools with good UI design. Good UI decreases the overhead of effort involved in both learning and carrying out the task at hand (and doing it well is even better).
As for teamwork, you could really just take the first two text boxes of the comic and fill them with the Gaslamp-conflict-of-the-week while making sure they’re between the two appropriate personalities. These things write themselves.
