I’ve been developing software professionally for more than 10 years now, but it’s always been a very engineering and developer heavy environment where things like look and feel, coherence and clean interfaces have been something people had to do in their spare time.

So when I started working with Ollie, there were major differences between the way I used to work and the way this app has been developed.

Some observations:

• Comparing my own designs with a pro’s designs leads to inferiority complex
• When I think something’s done, it’s only halfway there
• The end result is amazingly coherent

It’s also a much more drawn out process as there usually is a number of iterations where an idea turns into a design that finally turns into an implementation. There are usually somewhere between 4-5 rounds of tweaks before we end up with the final implementation.

If one chooses to divide up labour the way Ollie and myself did it, there is a very clean interface between the designer (Ollie) and the implementer (me).

I get designs, screenshots and other specs, and Ollie gets 3-4 builds a week with the latest improvements in them (I usually throw some bugs in there as well to keep things interesting).

(I know Ollie is a very good developer – so going forward we will probably blur the lines a bit more).

So how does this change the dynamics in terms of what one can hope to accomplish? There will always be a trade-off between what is possible, what is desirable, what is acceptable and what the total workload is.

Unless you happen to be have an unlimited R&D budget you will most likely have to decide if you want to have a release that has a lot of features with less TLC per feature or if you want to spend a lot of time perfecting a limited set of features.

I strongly believe that in order for a small group of people (think two!) to be able to develop, maintain and support an application, the latter approach is the one to go for. It’s also a lot more rewarding in the end, one can focus on the next small batch of features and trust the fact that the app is well put together, coherent and doesn’t need a lot of support. The app will stand on it’s own.

The inherent problem with a small set of features is that you won’t have the benefit of the shot-gun feature approach. If your few features aren’t appreciated, then you’ve spent all that time in vain. Which will probably suck a great deal.

This is where working with a good designer will help a great deal. The starting point is usually about what the next useful feature should be and how the user should interface with it, not about what features are simple to implement given the existing code or how one can fit a cool piece of code into the app.

Given everything I’ve written above, how well did myself and Ollie do?

Well – you tell us

Great news, Magnus’s Online Chess has just been submitted to Apple for approval. Judging by the latest wait times, that should mean the app is in the app store in the next few weeks!

We’ve decided to release it as a free app with a paid update to unlock some of the features. This means that you can try the app for free and play unlimited games as a guest. If you upgrade, you’ll unlock the ability to log in as a registered user, play rated games and keep track of your rating.

Unlocking all premium features costs $2.99 (USD)