You’d think that working on my own I would practice all those software development practices that I complain bitterly about when I’m working for others, but no. But really, it’s the exception that proves the rule (I never really understood what that phrase meant). I haven’t changed my mind about this stuff – my own non-compliance just reinforces how important they are:
Version control – I would really, really like to use version control and have a bunch of stale svn repositories to prove it. I did stick to it while messing around with Java, but I can’t use it with Unity without very very careful planning, until they provide integration that lets me move stuff around with creating havoc. It’s not so bad considering I’m not team-coding with anyone and I don’t have to monitor who changed what, but if I have to roll back changes more than a few days, I’m screwed. That said, I have been putting some public stuff on github.
Backups – well, I’m using Time Machine, which seems to be a lot more reliable than many corporate backup systems I’ve seen (some of which have turned out to have backed up nothing, at an inopportune time). And it has nice GUI, which I’ve used a few times to roll back (see previous). But operating cheap, I have a pitifully small Time Machine drive which just gives me about a one-month history. And it’s local storage, like six inches from my Mac, so some physical catastrophe happened to my Mac it’s very likely that Time Machine would go with it. So I still occasionally make CD copies and put those in a bank safe deposit box.
Daily, automated, clean builds – nope. Again, I did have some nice clean ant build scripts for my Java stuff. For Unity, nada. Although I know there is some batch support, so I should look into that more.
Testing – pitiful. It could be worse. I have a handful of iOS and Android devices (three each), but I wouldn’t call it comprehensive. For a real company, there’s no excuse – sure, hardware adds up, but it’s still negligible compared to one employee salary. For me, however, each piece of hardware is significant compared to the cost of buying groceries.
Code freeze. On a real team project, I like to clamp down on changes at least a few days before the release. I’m more reckless on my own projects, but there’s a method to my madness – I’m more careful with my more important apps, like HyperBowl on iOS, but I’ll experiment with the free versions first, and I treat Google Play as experimental sandbox (that’s what you guys get for only downloading free apps).
Code documentation. Minimal. Usually after I’ve confused myself at least once.