Semantici.st

I’m going to start by proposing the following:

Doing it right > doing it wrong > not doing it at all.

I do firmly believe that in terms of software development, test-driven development (or ‘test-first’, or ‘behaviour-driven’ development, which all seem to be variations on a theme) is the right way to do it. You get excellent automated test coverage and that gives you the confidence to say that your code does what it’s supposed to and to refactor it without worrying about breaking things. Especially in the Ruby community, tests are the norm and writing your tests first is held as both a ‘best practice’ and the norm for many developers.

I really suck at doing TDD, and that’s stopped me from doing any development at all. Because I know that I ‘should’ be working in a certain way, but I’ve not quite grokked how to do it that way yet, I end up doing nothing at all. Ultimately I need to understand why TDD is messing me up like this, but in the meantime I’m going to just write code and worry about testing later. At this that way I’ll actually produce something non-trivial, and some of my more interesting projects might actually see the light of day. (One of them definitely will, but I’ll be writing about that later.)

I have some ideas for why TDD just doesn’t work in my head. As I understand it, the idea is to write tests for the ‘code you wish you had’, which will fail, and then you write that code. I can how that would be really useful for experienced or well-trained developers, but I’m neither of those. I don’t do software development in my day job (and when I am forced to write code, it’s horrific perl hacks, so I don’t even want to do software development in my day job). I don’t have an academic background in software development (I studied psychology mainly, and didn’t even graduate anyway). I think I make a fairly good Linux systems administrator (I have relevant experience in that area, and a really good Unix Beard), but knowing how a computer system works doesn’t magically grant you the knowledge of software application design that’s drilled into the heads of Software Engineering students at uni.

I think my problem is that I’m not sure what the ‘code I wish I had’ actually is until I write it. I’m not sure what to write tests for until I have some code already – and that violates the basic premise of TDD.

Over time I want to correct this, and I think the best approach is to write actual code and make it work – which will give me experience – and to perhaps spend my daily commute reading up on software engineering theory. I’m not entirely convinced about the second part, since it sounds really dull. I’m by no means certain that software development is what I ever want to do full time, but I am certain that whatever I end up doing for a living I’m still going to want to use software development to realise the ideas and share them with the world.