I know that a lot of you visit my blog because I am the Internet’s apparent authority on how much git sucks, so I’m sure you’ll appreciate what I have to say here. Revision Control systems, and test-driven development — in particular, unit testing — are harmful to computer programming.

Consider that little app or script you wrote a few weeks ago to solve some immediate problem, or immediate whim you had. It was pretty easy, you opened your favorite text editor with a clean, inviting blank page and a flashing cursor and started typing with no real thought about where was best to start.

If you were writing in a real programming language you probably compiled and ran a pretty early version of some piece of code, with a frivolous main() function to call into it, and you iterated pretty quickly adding functionality as you went. You figured out problems using the debugger, hooking into the code you needed to debug directly so you didn’t have to go through the whole thing just to get to the bug.

If instead you wrote in something like Python or Ruby you probably fired up the interactive interpreter in another window and as well as running your script from time to time, you probably copy and pasted stuff into the interpreter to figure out as you went. I’m terrible for always checking my string chopping code in the Python interpreter as I write it. You don’t have a real debugger, but it helps.

Anyway my point is that you quickly got started, and probably got something working pretty well in a relatively short amount of time and you had fun doing it. Nothing seemed too much of a road-block.

Now consider the last time you wrote some “serious” code “properly”, maybe for work or last time you attended a lecture on the benefits of test-driven development or when you were working on a project that had to go into revision control.

So okay, to get started first you need to make the project directory and run git init.

Well, that’s our first problem. We’ve got to make the project directory, damnit, what is this going to be called? It needs a name! We can’t just call it sunday-play-lens because this is going in revision control, and if I call it that now it’ll forever show up in my revision control history.

A few days later, you’ve got a name, and can finally make the directory. Hurrah! Now we run git init and we can get started. We pull up an editor — hopefully it’s still your favorite, and that your employers don’t force you to use Eclipse or something — and there’s that fresh blank inviting page again.

So where do we start?

Oh god, this is going in revision control. After I’ve finished this, I’m going to have to type git commit. That’s going to be permanent. If I screw up now, my screw-up is forever going to be visible to the world in my revision control history.

Ok, well there is something I can get started on; I know I need a priority queue class for this code, and that’s easy enough to get going with. I even know it’ll be called NIHPrioroityQueue so I don’t have to worry about that, and can even unit test it. It’ll get committed as a nice unit “NIHPriorityQueue – implement priority queue” goes the commit log.

Phew, thought we weren’t going to make it there, but now the project is definitely started. I have a priority queue, and I have some test cases.

What do I work on next? I don’t dare go near the main() routine, I’ll have to keep changing it in the commit log – and how do you unit test it? I know this code will need to grab some data from a RESTful API and parse it, so I guess I’ll start with that.

Ugh, I don’t really know where to begin; I guess I’ll have to just start with an asynchronous network library and a main loop to integrate it with. If I were doing this as a hobby I’d've just hacked it synchronously, but this isn’t a hobby, this is serious – people are going to read my commits and shake their heads if I do that.

And so on.

The only thing that changed is you added the requirement that it be written “properly” and now the code that would’ve taken you an afternoon to write is taking you months and you’re getting nowhere with it.

Why? Because you can’t play anymore.

The need to commit and test your work as you go means you feel like you have to get it right each and every time, it’s going down in stone and that means it has to be perfect. Even worse if you have to get code review as well.

Without the ability to play around, mess about with the code without consequences and privately on your own computer, you can’t be truly creative with it; and if you’re not being creative, it isn’t fun!

Now, that said, if you try and inflict on the world another untested heap of messy code without any trace of tests and with no clear revision history, then you’re going to the special hell.