The lessons of a mini-developer

Dr Neil Paul

In a previous column, I mentioned that I had taught myself Objective-C and all the bits associated with it and that I had written and released my first iPhone app, a JBS2 primary prevention risk calculator called iCalcRisk.

Since then lots has happened. My second app called iMCQs in Dermatology was released and is available on iTunes and I have also launched another app called iMCQs (casebook of primary care) based on the award winning books Carebook of Primary Care and Atlas of Dermatology. I’m working on several sequels.

I mention this not only as advertising – although if you are interested in writing some MCQs for a share of the income please contact me ( www.imcqs.com) – but because being a mini developer has given me some useful insights into the software business that I’d thought I would reflect upon.

Lesson one

I have learnt that feature creep is a nightmare. It was easy to keep thinking of new features to add, and since I found writing the code enjoyable it was easy to get lost in it.

Delivering a product by a certain date meant very clearly defining what was version 1.0 – and I can see now why some pieces of software don’t always do all that I’d like them to do. I also have more insight into why developers don’t always give clear development paths – it can be very difficult to know what will be easy to add and what will require a complete rewrite.

However, I am more convinced than ever that the user interfaces of GP software need more work. When I first showed my app to people, what I thought was a clever interface confused them. They all thought it should work in a different way.

I swallowed my pride and changed it, which took some time. Hopefully, I have a better product. I believe Microsoft does this a lot. But I wonder how much GP software suppliers do? There are several programs I use daily that make no sense in places, have laborious ways of doing things and generally get on my nerves.

Lesson two

I found it easier to concentrate on new features than bug testing. Just before I submitted my app, I tested it again and found a couple of memory leaks that took a couple of days to track down. I also spent a day or so testing it to its limits to make sure it didn’t crash.

Thinking about it, I’ve rarely come across any major or minor bugs in GP software in over 10 years and I think the software companies should be congratulated on this.

On the other hand, I don’t rate a lot of the user guides and built-in help for most of the software we use in my surgery, and I’m sure this means that a lot of users don’t know all of the features available or use them effectively.

Internet based guides and tutorials may be the way to keep things up to date and to solve distribution problems. However, I’ve just surfed several software suppliers’ web pages and it’s difficult to find good user guides or tutorials on most of them.

Is this because there is a market to be had in training and they can charge for it? Or is it that we are a captive market that just keeps paying annual license fees and this leads to complacency?

APIs for the NHS

My apps are highly reliant on Apple having well documented APIs. For the uninitiated, APIs are publically documented codes in a piece of software or operating system that allow third party software to talk to, interact with and in some cases control it.

Microsoft has these for its Office suite that you can access through Visual Basic and Apple has something similar called AppleScript.

I have long been an advocate of more of this interoperability in GP software, as it should allow a plethora of third parties to create new interfaces, add functionality and plug the gaps that a large company may miss (though there are downsides as well).

Emis, I know, has a limited API that is available to developers, but I’m not sure how many of the other companies do and I’m not sure how feature rich they are.

I wonder if one of the roles of the National Programme for IT in the NHS might be to decree a basic set of API calls that would allow different apps to work together, much as it sets standards like HL7 and SNOMED CT so systems can exchange information with each other?

Dr Paul is a full time GP working at the Ashfields Primary Care Centre in Sandbach,Cheshire. He sits on his primary care trust’s professional executive committee and has a lead role for IM&T and practice-based commissioning. This column first appeared on Microsoft’s NHS Resource Centre.