Software, Abstract Strategy Games & Other Stories

Moving Blog

2010-12-18T12:28:00.000Z

This will be my last post here, I am moving my blog to http://mpatric.com.

My new blog is a custom-built Rails app, hosted on Heroku, using Gravatar for avatars, Akismet for anti-spam and Amazon S3 for storing assets.

Is reversi too difficult?

2010-03-20T23:53:00.017Z

Much time went into making the AI of reversi strong enough on its higher levels to challenge human players. The highest three levels (of the seven available) are challenging for most human players. On the lower levels, the intention was for it to play as a novice human would play. On the lowest level (beginner) in particular it plays for short-term gains, without considering longer term strategy at all. On each turn, the beginner level plays the move that flips as many of the opponent's pieces, taking a corner if one is available and avoiding squares that would give the opponent a corner on the very next move. This reflects the basic manner in which most novices would tend to play reversi.

Playing each of the other levels 100 times against beginner results in beginner level being whipped 100-0 by every other level. So, it's significantly weaker than all the levels above it, including the one directly above it (intermediate).

All of this makes some of the comments in reviews for Reversi on the App Store all the more surprising:

"Othello is an awesome game I really enjoy playing it but this game is way to difficult even on the easiest setting I cannot beat this game even once I think you should change that" - BjMiller20, Jan 2010

"..it's too difficult to win even on the easy setting. After playing it just a few times, I've given up on it. It's no fun if you don't feel like you even have the slightest hope of beating the computer and on the easy setting, you should have at least a 50/50 chance." - Mitchipoo, Jan 2010

"..frak me, the AI is ridiculous! I've played this game for years but I can't beat the game on Beginner! I'm not Einstein, but I should be able to win at that level.." - Nuclear Moose, Oct 2009

Is beginner level really too difficult? I have played against it dozens of times and beaten it without really thinking about where to play, but I'm probably not the best yardstick as I've played thousands of games of reversi.

I thought a good, objective test of the difficulty of the beginner level would be to see how it does against a player that makes completely random moves on every turn. Surely if the player making random moves manages to win a few games, then the AI of the opponent player is weak. With this in mind, I pitted beginner level against a bot playing random (valid) moves on every turn; 100 games with beginner playing black and the random bot playing white, followed by 100 games with colours switched. The results of the 200 games were as follows:

164 games won by beginner (80 as black, 84 as white)
29 games won by random (11 as black, 18 as white)
7 games drawn

Beginner level managed to win 82% of the games against the random bot, suggesting that it is fairly weak.

Most people that have played reversi know that corner squares are important and often determine who wins the game. Adding two very simple rules to the random bot, which are to play a corner if one is available and to avoid playing squares that give away a corner to the opponent on the very next move (otherwise, just to play randomly as before) changes the results to:

85 games won by beginner (40 as black, 45 as white)
111 games won by random (53 as black, 58 as white)
4 games drawn

From this we may conclude that beginner level is pretty weak. It is beaten often by this simple bot. It would only be weaker if it intentionally played moves that were advantageous to the opponent - in other words, if it played to lose. It would appear that amazingly enough some human players play in this way, perhaps thinking they're playing good moves. To those complaining that the beginner level on reversi is too difficult, it really isn't. Learn some basic strategy and you'll find you will be able to beat beginner level quite easily.

UPDATE: The difficulty levels have been spread out a bit, so beginner is now even easier.

Unethical practises on the App Store

2009-06-20T20:34:00.006+01:00

Every iPhone app developer goes through great pains to get their apps noticed and hopefully to break into the charts, which will result in increased sales. Rather than building great apps to entice buyers, the approach some devs take is to release crapware and then to dishonestly fill the App Store with five star reviews that rave about the brilliance of their apps, enticing many gullible users into buying them in the process. Whilst I understand the difficulty that all devs have in promoting their applications, Apple should draw the line at this sort of unethical behaviour.

"Hold on!" I hear you cry. "How is this even possible? You need an iTunes account to place a review and creation of an iTunes account requires the entering of personal details and credit card information!"

Yes, you do need an iTunes account to place a review; however an iTunes account can be created quite easily using a promo code which EVERY developer on the App Store that has published applications can generate for their own applications. Personal details are not verified, so anything can really be entered. New email addresses are easy to generate. It wouldn't take more than a few minutes to generate each new iTunes account. This technique can currently only be applied to the US App Store.

Obviously, it's hard to prove which developers are doing this, however when it's done blatantly it's obvious. Take this developer for example, who has several applications on the App Store that all have suspiciously good reviews and ratings on the US App Store. Clicking through on each of the 'reviewers' reveals that each one has reviewed all of the developer's applications, giving five stars in each case and glowing reviews. The offending applications include My Othello and Reversi Extended (which look to be identical games).

Or course, I'm not saying these reviews were submitted using this trick; however the evidence is quite strong. Furthermore, these implementations of reversi are easily (IMHO of course) the worst on the App Store, yet have the best ratings (4 stars and 5 stars respectively on the US App Store, with 29 suspicious reviews each). The reviews are not true reflection of these implementations.

Hopefully Apple addresses this loophole, or the reviews in the App Store will become worthless. Thankfully, at this point it's only the US App Store that is affected; however, for most developers the US App Store is the most lucrative, so it might become difficult to compete with apps whose rating has been boosted using this technique. Apple, please close this loophole.

The trouble with timers

2009-05-15T17:50:00.010+01:00

On the iPhone it seems to have become commonplace to use a NSTimer to trigger redraws on OpenGL ES applications when displaying a changing or animated scene. To run smoothly, a frame rate of 30fps or higher is generally aimed for (60fps being the maximum, limited by the iPhone hardware refresh).

Relying on a timer to fire the code that renders the frame has its pros and its cons. The pros are simplicity and having everything in the same thread of execution (or runloop) means not having to worry about concurrency issues. The cons are what I'm more interested in..

The NSTimer class reference states: A timer is not a real-time mechanism; it fires only when one of the run loop modes to which the timer has been added is running and able to check if the timer’s firing time has passed. Because of the various input sources a typical run loop manages, the effective resolution of the time interval for a timer is limited to on the order of 50-100 milliseconds. If a timer’s firing time occurs while the run loop is in a mode that is not monitoring the timer or during a long callout, the timer does not fire until the next time the run loop checks the timer." Therefore, the actual time at which the timer fires potentially can be a significant period of time after the scheduled firing time.

The low resolution and the fact that a timer can misfire (skip frames) are the most worrying for me.

A frame rate of 60fps means a timer period of 1/60 = 0.016667 seconds (or 16.667ms). What this means is that the frame needs to be rendered well within 16.667ms or the timer will misfire. Flipping buffers when rendering an OpenGL frame can block, depending on the hardware refresh sync, making the likelihood of an overrun (and subsequent misfire) even higher.

What typically happens is the timer fires every 16.667 ms or so (depending on what else the run loop is up to), but for frames whose drawing code has not completed by the next time the timer is meant to fire, the subsequent frame is effectively skipped.

A misfire results in the time between two ticks suddenly being twice the expected period (or possibly a higher multiple of the period if the overrun in the rendering is even higher). Depending on the way in which the animation is implemented in the application, this will usually cause a visible blip or stutter. Regular misfires would make the animation appear jittery and unpleasant.

As most developers simply add the timer to the main runloop, it means that the events need to fire in between whatever other code the main runloop is executing (in particular, user events). This can add inconsistency to the timer period.

Things that can be done to improve this situation (many of which can be done together) are:

Optimise the drawing code so that it comfortably completes within the timer period (16.667ms for 60fps). If it's far under this threshold, then the other things happening in the runloop shouldn't regularly push it over the threshold.
Change the animation code so that it does not expect a regular period and animates the scene based on how much time has passed since the last animation. This is not always feasible - see this time-based animation tutorial.
Set the timer on a seperate thread (not the main thread).
Use a thread with its own custom loop rather than a timer. This in itself is not a solution if the rendering regularly exceeds the desired frame rate period, however can improve the smoothness of the animation when combined with some of the other things in this list; it also gives you greater control over when to draw the next frame when the previous frame has overrun, instead of being forced into multiples of the timer.
Increase the timer period and only render the scene when an appropriate amount of time has passed (oversampling).
Decrease the frame rate; however it can only be decreased so far before it starts to look bad.
Decouple the drawing from code that is not directly related to rendering (such as physics simulation or animation logic) - see this blog on fixing the animation timestep for a good overview of this approach.
Synch to the hardware refresh. This is typically what console games do and would be the best approach in many situations. Unfortunately this not currently possible on the iPhone as no hook or callback is provided by the underlying APIs.

My preferred approach is a combination of 1, 2 and 4. If option 8 was available I would go for a combination of 1, 2 and 8.

Rise of the crapplication

2009-05-12T10:43:00.013+01:00

There has been chatter of late in the iPhone developer forums that I frequent regarding the prolifation of crap applications (crapplications, or simply crapps) in the App Store and that the App Store model encourages this. Could this really be true?

Like many others, I have a full-time job and just develop iPhone applications in my spare time. But that does not mean it costs nothing to develop my applications. On the contrary - my spare time is very valuable to me - but how do I quantify it? If you assume that I did some other work, say contract work, over that time then the opportunity cost of this lost income can be determined.

With this in mind, I decided to examine one of my applications, Magnetic Block Puzzle to see what the cost of developing it was and what sort of sales I would need to achieve to break even in a reasonable period of time.

Magnetic Block Puzzle deconstructed

I estimate that it took around 200 - 300 hours to develop, from start to release-ready code. In order to calculate an opportunity cost for this time, I need to determine an hourly rate. Conservatively I am using a rate of £30 per hour. That equates to an opportunity cost of £6,000 to £9,000. For the rest of this exercise, I will use the average of £7,500 (about $11,500). Expenses incurred in developing the application have been ignored.

So, how many sales are required to break even?

Tier	Price ($)	Price (£)	Pre-tax profit (£)	Req sales
Tier 1	0.99	0.59	0.36	20,833
Tier 2	1.99	1.19	0.72	10,417
Tier 3	2.99	1.79	1.09	6,881
Tier 4	3.99	2.39	1.45	5,172
Tier 5	4.99	2.99	1.82	4,121
Tier 6	5.99	3.49	2.12	3,538
Tier 7	6.99	3.99	2.43	3,086
Tier 8	7.99	4.99	3.04	2,467
Tier 9	8.99	5.49	3.34	2,246
Tier 10	9.99	5.99	3.65	2,055

I need to sell 10,417 copies at its current price of £1.19 ($1.99) just to break even! How many sales are required then, per day to break even in six months?

Tier	Price ($)	Price (£)	Pre-tax profit (£)	Req sales per day
Tier 1	0.99	0.59	0.36	114
Tier 2	1.99	1.19	0.72	57
Tier 3	2.99	1.79	1.09	38
Tier 4	3.99	2.39	1.45	28
Tier 5	4.99	2.99	1.82	23
Tier 6	5.99	3.49	2.12	19
Tier 7	6.99	3.99	2.43	17
Tier 8	7.99	4.99	3.04	13
Tier 9	8.99	5.49	3.34	12
Tier 10	9.99	5.99	3.65	11

57 copies a day at the current price doesn't sound too bad until you consider that it needs to maintain this level for six months and that on its best sales day it hasn't come close to this amount. It's looking unlikely that I will break even on this any time soon, if ever.

What are the options then? Raising the price requires fewer sales to break even, but raising the price will result in a decrease in sales too, so this is unlikely to help.

Perhaps lowering the price to 59p ($0.99) will help boost sales? It probably will, but at that price the required number of sales to break even shoots up to 20,833 or 114 a day for six months.

The only other option is to lower the development cost. In other words, spend less time developing it in the first place. Too late for this application, but valuable information to take to the next one. Knocking off 10% or 20% is not going to change the situation much. The decrease needs to be significant (say, an order of magnitude). Putting 20 - 30 hours of effort into building an application means an opportunity cost of around £750, which can more realistically be recouped through App Store sales in an acceptable period of time. But what can be built in 20 - 30 hours? Ah, a crapplication.

Pricing

The above logic of course assumes that a crapplication will sell as well as something that took ten times longer to develop. Unfortunately, the history of the App Store leads me to believe that you are no more certain to sell something good than you are to sell something crap. If it appeals to the masses, it will probably sell, irrespective of how bad or how good it might be (this is the best example of the former).

A popular story that is quoted is the developer that decided to see what could be built in an hour; came up with Sound Grenade in 20 minutes and landed up cracking the App Store top 10 with it.

The blessed / dreaded charts

To break even many sales are required at a low price, or fewer sales at a higher price. In pre-App Store days people would happily pay £5 to £10 ($7 to $15), or even more for a mobile application. Ringtones and images were confined to the price brackets below this. The App Store has changed everything. Customers now expect to be able to buy just about anything for 59p ($0.99). It wasn't always like this - I remember the first few apps on the App Store being more costly. Didn't I purchase Super Monkey Ball and Enigmo for £5.99 ($9.99) each? Yes, I did. What happened?

This slide can arguably be attributed to the App Store charts. The charts are just based on downloads, irrespective of cost. So, a £5.99 ($10.00) application would need 10 times the turnover in order to compete with a 59p ($0.99) application in the charts. Of course, this is a losing battle. Surely charts should take the price into consideration? As it stands, it has clearly become a volume game.

Getting a spot in the App Store charts is essential for every developer. The charts tend to be self-perpetuating. Once an application is in there, it is noticed by more people and therefore downloaded more, boosting its position in the charts, leading to even more people noticing it and so on.

It seems then that developers have little choice but to charge 59p ($0.99) or £1.19 ($1.99), or at a push £1.79 ($2.99) and hope they crack the charts. If they don't, the application is quickly confined to the abyss of unnoticed applications (AUA), picking up the odd few sales here and there, but ultimately not very many.

Summary

It would seem that the best return on investment is to spend as little time as possible building an app, try to give it mass appeal and price it at tier 1 (59p or $0.99). Perhaps then building iPhone software with the aim of making money is viable.

If like me you have spent a significant amount of time building applications, for very little reward, console yourself with the fact that many of us are in the same boat. Let the enjoyment of building the application be your reward and the sales (if there are any) be a nice bonus.

New iPhone puzzle game

2009-04-22T10:26:00.011+01:00

Magnetic Block Puzzle is now available on the App Store for a small amount.

It's a departure from my two previous games, Reversi and Merelles, which were both abstract strategy games. Magnetic Block Puzzle is, as the name implies, a puzzle game. The aim of each of the 110 puzzles is to join the coloured blocks, which are special magnets that stick to other blocks of the same colour, by tilting the puzzle to make the blocks move.

The process of building this game, from inception to completion, went something like this:

I started out this project by building the underlying model of the blocks and the board, including the logic to shift the blocks around. This was done in a test-driven manner, which helped to drive out the model and behaviour correctly and to identify edge and corner cases early. Towards the end of this process, I discovered a similar puzzle game on clickmazes.com and contacted them to ensure I wouldn't be violating a copyright. They were happy for me to proceed and gave me permission to use two of their puzzles too.

The next step was to build a solver and a puzzle builder application on top of the model, to allow me to design and test puzzle layouts. This was done as an iPhone application and many puzzles were designed on my iPhone whilst I was riding on the tube :)

Once enough puzzles had been designed, I tailored the solver to determine various things about each puzzle such as the number of solutions, the number of moves in the best solution, the number of useful positions in the solution tree (positions from which the puzzle can be solved), the number of dead-end positions (positions from which the puzzle cannot be solved), and so on. This proved to be quite CPU-intensive on the more complex puzzles, so it was compiled and run on my Mac rather than on the iPhone. These values were then used to assess the relative difficulty of each puzzle.

So, every puzzle included in the game was designed by hand, but assessed and verified by code.

Finally I wrote the actual application, including in it the 110 puzzles that had been selected for the final application, in a local SQLite database. Like the solver and the puzzle builder, the actual game was built on top of the model built initially.

I started this application in early December 2008 and finished it in late April 2009 - nearly five months of much of my free time went into building it. I am happy with the end product and hope that those who purchase it enjoy playing it as much as I enjoyed creating it. It's available on the App Store now.

Merelles iPhone game released (finally)

2008-11-16T20:35:00.001Z

I've been working on Merelles for the last 4 months and I'm pleased to say, I've finally finished it. It's available on the Apple App Store for a small amount.

Merelles is an abstract strategy game. It is also know as Mills, x Men's Morris (4, 6, 9 and 12 men variations) and by many other names.

Seeing as this is my technical blog (and the Apple NDA has been lifted), I feel compelled to provide some technical details. The app itself is written in Objective-C (of course) using TDD (of course!) driven by OCUnit.

The computer AI uses a negascout tree search to examine the game tree. The use of the negascout algorithm means that some pruning will occur on the game tree so that not every node needs to be examined, as long as the moves are ordered so that better moves are examined first!

Iterative deepening is applied on top of this, starting by searching one move ahead, then two, and so on. The moves that look to be good after a search are considered first when searching deeper. In addition, as the same board position can occur several times during a single tree search, moves that result in a really promising board position are classified as killer moves and examined before other moves if they occur again during the search. All this helps in obtaining an amazing prune rate of more than 90%

A question that is often asked is how do you determine if a board position is better than another board position? Unfortunately, it's a fuzzy answer. A set of heuristics is applied, which take into account things like how many pieces each player has in play, how mobile each player is (how many valid moves they have), how easily they can form a row of three pieces, and so on. The strength of the AI is determined largely by these heuristics.

There are 3 difficulty levels. For each level, the heuristics are mostly the same, with varying depths for the tree search and the maximum number of board positions that are considered. For the most complex game (the 12 men game):

On easy, the AI only looks 2 moves ahead.
On medium, the AI looks 2 to 4 moves ahead examining up to 3000 board positions.
On difficult, the AI looks as many moves ahead as it can in examining up to 15000 board positions - in practice this is between 4 and 8 moves ahead, depending on the state of the game.

The resulting game play feels quite natural to me, with the AI coming up with some clever strategies, which in themselves have not been programmed into it, but rather are the result of the tree search and the heuristics. I've been astounded a few times at the way it has trapped me!

The primary challenge in writing this game was to balance the heuristics to set up board positions that would yield good results later in the game rather than just constantly pursue the capture of opponent pieces, which would result in rather one dimensional game play. On top of this, it was necessary to keep the calculations light and to optimise the code as much as possible so that the tree search would not take too long, remembering that it's running on a device with limited computational power. On difficult, the deepest tree searches take up to just over 4 seconds on the iPhone.

Unit testing iPhone applications

2008-08-27T17:23:00.001+01:00

The OCUnit framework is bundled with a standard xcode installation, which is handy for getting up and running with unit tests and test-driven development (TDD). Somewhat annoyingly though it does not play nicely with the Cocoa Touch framework. So, how does one go about building iPhone applications using TDD? I'm sure there are several ways of achieving this, but I wanted to stick with OCUnit. After a bit of messing about this is how I do it.

Image from Bhavna Bahri's photostream.

The Cocoa Touch framework encourages the use of the model-view-controller (MVC) pattern. It's only the 'V' and 'C' bits however that need to extend Cocoa Touch objects (UIView and UIViewController); you're completely free to implement the 'M' bit as you see fit. So, the basic approach I take is to write the model classes against OCUnit tests compiled against the (Cocoa) Foundation library only, and to then use these same classes in my iPhone application, which is compiled against the Cocoa Touch framework. The Foundation library exists in both the Cocoa and Cocoa Touch frameworks and is (almost) identical, although the unit tests only run against the Cocoa version.

This setup involves creating two projects: a Foundation Tool project and a Cocoa Touch project, and to reference the model code (which lives in the Foundation Tool project) directly from the Cocoa Touch project. Rather than duplicating the files that comprise the model, they are just referenced from the Cocoa Touch project (which is achieved by dragging them from the finder into the Cocoa Touch project, making sure the 'Copy items into destination group's folder' option is not checked).

The files that comprise the model objects should import Foundation/Foundation.h whereas the files in the Cocoa Touch project should generally import UIKit/UIKit.h (which is a higher-level header file that ultimately includes Foundation/Foundation.h).

What this means is that unit tests only cover the model, not the controllers or the views - so domain logic should be in the model, with the controllers simply acting as conduits for responses from this logic. In other words, there should be as little domain logic as possible in the controllers (and obviously the views, but there should not be any logic in the views anyway!)

App Store Trials and Tribulations

2008-07-15T12:54:00.002+01:00

I got my first iPhone application submitted and accepted onto the App Store for its launch. Here are my impressions of the process so far.

As a developer, once you've built an application and tested it on the device, and digitally signed it with an Apple-issued distribution certificate, the application is submitted to the App Store via iTunes Connect, which is a simple web application. All the meta-data for the App Store is entered at this point. I have a few small gripes about it and was hampered by a bug that didn't let me change details on a subsequent upload, but otherwise it's simple and does the job.

The application only appears on the App Store once it has been reviewed and approved by Apple. The first time around this took two days, but the rate at which they are approving releases seems to have slowed to a crawl now. I submitted an update more than a week ago, which has yet to be approved. In fact, I now have another update ready (which should be my last). My concern around the slowness of the approval process is that if there is a pressing update you need to roll out, it will take as long as Apple decide it will take and as a developer you have no control over this.

Once the application is on the App Store, you are at the mercy of the iTunes community. I am not convinced that the reviewing mechanism used for music is appropriate to applications. I've had several low ratings (zero or one star) simply because there is a free version of something similar and mine costs £1.19. Being as objective as I can, I can honestly say that the free version is free for a reason - it's not very good. Allowing people that haven't even downloaded the application to give it a rating is opening the door to this sort of abuse. It can be really gutting to see your rating drop, especially when the reviewers haven't been fair, or even downloaded the application in the first place. This of course has the knock-on effect that fewer people download it because of the low ratings. Given the months of hard work that went into producing my application, I can't understand why someone that hasn't downloaded it is able to review it and thus directly impact how many people are likely to download it. Apple, you need to change this!

My last gripe is that Apple don't provide any download statistics to the developer. A monthly report is produced, but in the fast moving world of online sales surely daily stats wouldn't be too much to expect?

Update: old news now, but Apple are providing daily and weekly stats.

New domain name shortage

2008-06-27T15:06:00.001+01:00

I was recently looking to register a new domain for a project I've been working on. I underestimated the amount of time it would take to find an available domain. What's incredibly annoying is that many domains have been registered purely in an attempt to make money by selling them on (especially .com domains). Let's face it, everyone wants a .com domain.

Here's an experiment to try. Think of an obscure word or combination of words that surely nobody would have thought to register, and do a whois check on it. You'd be suprised at the domains people have registered (I was).

Let's try some... How about eatbananas.com or flybot.com. Nope, both taken.

Ok, how about purpletree.com, happycow.com and satisfiedmonkey.com? Taken, taken and taken. Yes, satisfiedmonkey is taken.

Maybe the trick is to find something that's not really a word. Something cool like digg or boingboing. How about kerplunk.com, sproing.com, flugle.com or cartoo.com? Ah, no, all taken.

Maybe the trick is to leave out letters like flickr? How about shattr.com or shtterbug.com? No.

Should it really take a day of hitting whois with odd words until amazingly you manage to find one that is available and not completely ridiculous? Shouldn't domains have a use-it-or-lose-it rule? Should there be a limit to the number of domains one can register? Until then I guess we're doomed to having lots of startups with absurd names because that was the best .com domain name they could find.

South Africa and Open Source

2008-05-22T22:21:00.001+01:00

Last year, the South African government announced their intention to roll out open source implementations across all government departments. A move that surprised, but delighted me and many others.

So, when statements are made like the one made recently by Microsoft's director of corporate standards that South Africans were unlikely to benefit from OSS, or do any 'deep' development work on Linux (hello, heard of Ubuntu?), I have to ask myself, where is this coming from? What is a statement like that aimed at achieving? Furthermore, saying that students in South Africa are 'still grappling with coding skills' smacks of complete ignorance.

While I don't agree with all the government's policies, they should be applauded for the move to OSS and for setting a precedent that other developing countries in Africa may follow. Well done!

Raising the bar on bug priorities

2008-05-21T16:39:00.001+01:00

Inevitably during the course of writing an application, bugs creep in. And like all good software teams we diligently capture them, along with some priority level. Let's say for the purposes of discussion the priority levels are: trivial, minor, major and critical. Fine. So far, so good. But, as time goes by and bugs get raised and some get fixed, the way in which priorities are determined seems to change. If the entire bug queue does not get cleared out regularly, what was minor before starts to become major because the people raising the bugs know that it will be fixed sooner. The result is that most of the bugs tend to land up in the next-from-top priority level (major) and before long the lower ones (trivial and minor) become little more than an afterthought. The highest priority level (critical) is usually spared as it is those bugs that really are showstoppers that still fill this priority level. It's not uncommon for a new priority level to suddenly be introduced to start separating the major bugs out into the more major and the less major bugs. This sets a dangerous precedent - what's next: Even more major? Almost critical? Aargh..

This seems to be a fairly common problem, seen in many organisations, on teams of varying sizes. As I see it, some of the root causes are:

Letting the bug queue grow too big
Not defining exactly what is meant by each priority level
Having too many stakeholders. Whose priority is more important?
Complexity or difficulty in fixing a bug are not interchangeable with priority - just because a bug has a priority level of 'trivial' it doesn't mean it will be quick to fix; and vice-versa.

Getting into iPhone development

2008-05-19T23:36:00.002+01:00

So, I have an iPhone, I have a Mac and I have some ideas. It seemed only right that I combine them and build an iPhone application. Only problem... I hadn't done C or C++ in years and Objective-C looked a bit daunting. But, what the hell, I took the plunge.

I am happy to report that it's not too bad. Working in xcode however is nowhere near as rewarding as IntelliJ or Eclipse. Just setting up my project to use ocunit (see update for more on this) so that I could start with some tests and step through my tests with the debugger required a few hours of searching the interwebs and some messing about (thanks Chris Hanson for this good short guide) . You'd think they would make creating a new project would add unit testing to it by default. It still comes as a surprise to me that people don't automatically write unit tests. Can software really be built effectively any other way??

All in all, the experience has been good. I'm just getting to the point now that I'm starting to put the GUI together. More to come on this.

Update: now that I'm building the GUI, I've switched to the Cocoa Touch sdk and it seems that ocunit does not work with it yet, which makes TDD (with ocunit) difficult. For now, I'm testing my classes with ocunit compiled against cocoa, then moving them to my cocoa touch application, but that's not a very good, or sustainable approach. The other options at this point are: write a simple testing framework; wait for apple to make ocunit compatible with Cocoa touch.