Elegant Chaos

Well my notice period is finished finally, and as of today, I am no longer working for Sports Interactive.

Instead, Elegant Chaos is fully back up and running, and I am planning to create and publish my own iPhone, iPad and Macintosh software.

I have a number of product ideas, ranging from the tiniest of utilities to some fairly large applications which may end up being long-term projects. Currently I'm aiming at the utility / general-purpose application market, and not at games. This isn't through any great bias one way or the other, but because I've always been a believer in making software that you need yourself, and right now there are lots of utility applications that I need. That said, I do have at least 3 game ideas which may see the light of day eventually. I'd love to work on games, but I think that they'll generally take longer and require more people, which isn't practical for me at this moment.

I am well aware, incidentally, that making a living as an indy application developer is hard, and I'm definitely going into this with my eyes open. You need good ideas, good execution, and probably a fair bit of luck too if you want to make proper money. Only time will tell if I can tick any of those boxes, let alone all of them at once. A few people have applications that are runaway successes, but the vast majority sell only a small number of copies, probably not even enough to cover the development costs.

So there's a possibility that I might not be able to do this full time, and might also have to spend some time contracting.

That's fine by me - I enjoy working with other people so a bit of contracting would actually be welcome anyway.

I want to give this indy thing a go first though - have some fun, learn some new things, and unwind a bit after years and years getting frustrated having to make things to other people's specifications!

It's a risk, of course, but every now and then, you have to take a chance. So wish me luck, and watch this space!

Occasionally I've had errors where Software Update refused to download something, telling me that I didn't have permissions to save the updated file.

In previous systems I think these files went into the /tmp folder, but in Snow Leopard they don't, and I've finally managed to work out where they do go - /Library/Updates.

On my machine, somehow, I'd ended up with a couple of folders inside this one which were owned by another user, and which didn't have group write permission.

To fix the problem, I did the following in a terminal window:

• > sudo chown -R :admin /Library/Updates
• > sudo chmod -R a+rwx /Library/Updates

You need to replace with your actual user name. In fact, I suspect that it doesn't matter who owns the files as long as they belong to the admin group, so if you want to be a little bit more security conscious, you could probably do this:

• > sudo chown -R :admin /Library/Updates
• > sudo chmod -R g+rwx /Library/Updates

I've been thinking about coding standards again recently. For me a coding standard should definitely be more than just about formatting and naming conventions. That stuff matters, but it's also relatively trivial to agree upon and then stick to.

Essentially I think the standard should clarify "the way we do things here" (wherever "here" might be for you).

The objective should be twofold:

• to educate everyone in your team, and teach them about good techniques and common pitfalls

• when there is more than one way to do something, to clarify which way to choose, so that code is designed in a consistent way and a programmer working in any area can intuitively work out how another area is likely to work, where to look when there are problems, and how to approach extending an area or adding a new one

My suspicion is that the exact choices that one makes when designing and implementing something often aren't the most important thing. In fact, too much choice can (and often does) paralyse me. Obviously avoiding really stupid decisions is a requirement, but after that, there may well be a number of adequate solutions to a problem.

The important thing when working in a team is consistency. If you're consistent, and agile, you can move fast. If everyone can understand the designs and the code, it will always be easy to revisit the occasional choice that turns out later to be wrong.

To achieve that, you need good standards, and you need good discipline. People need to buy into the idea of a standard, and try their best to stick to it, even the bits that they might not like.

In my experience, once you let go and just follow the standard, it's amazing how quickly a lot of those disagreements seem to become trivial and you are left free to concentrate on the important stuff.

That doesn't mean that designing a standard for a team is trivial. It's pretty tricky, but very important. Once it's done though, just go with it.