South Africa and Open Source

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

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

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.