Risk analysis

An important part of the development process, and especially at the start, is keeping an eye out for issues that could arise. And then just to be one step a head of the game, decided how you will get over those hurdles once they do come.

Hardware failure or loss of data is a constant concern since there are so many variables which make them so likely. It’s actually surprising how few cases of data loss I’ve come across. Between losing a flash drive, or a hard drive dying, or burst pipes destroying my machine, and the many hundreds of other ways which data can be lost, it’s always important to have a back up.

To guard against this risk though I’m using a distributed version control package (Git) to keep my code (and all my course docs) in a number of places, and all synced up at any one time. I have a repository on my laptop, on my desktop, and on my server. My server is hosted with AWS, and so is redundantly backed up by Amazon all over the world. To guard against bad administration of my server, and losing data that way, I have various snapshots of my server which I take once a week and keep for a month or two.

Another unlikely but constant threat is prolonged illness which means I can’t get work done on time. To avoid this I could make some lifestyle changes, like eating more fruit. However, if I do fall ill I have given myself a week at Christmas, and almost three weeks before the deadline which are empty on my Gantt chart. This time could be used to catch up.

An immediate risk is to do with the legal and technical issues around having the browser play an MP3 file. I’m not sure if modern browser support the playing of MP3 encoded audio files. This is an important issue since the majority of people keep their music in that file type. Without the ability for them to be listened to Sound Tiger will be almost useless.

Some quick research tells me that Firefox (my main browser, and so the one I most definitely wanted to support) doesn’t intend to add support for MP3 files. MP3 is a patent encumbered file format, but as is GIF and that’s still supported in every browser. Nevertheless, Mozilla have decided against adding support. There are javascript based tools to bring MP3 playing abilities to Firefox though. That means I’ll have to rely on the support of a third party library.

I’ve given myself a week of research time into the methods of playing audio though, which will including experimenting with that javascript library. If at the end of that week I haven’t been able to work out how to play MP3 files in Firefox I’ll have to withdraw support for it (as a user, and for Sound Tiger). Another way around this would be to attempt to convert the file formats into a more open format on the server, once a user uploads their music.

Ignoring the fact that I might not be able to use MP3 files for a moment, simply playing the files could be considered a risk to the project. The <audio> element, which would be used to avoid using Flash, is still fairly young both in the specification of HTML5 and in support for it with browsers. At any moment, a browser manufacturer could decide to withdraw support for it.

This isn’t very likely however. Other the past few years, most noticeably with Internet Explorer, browser creators are beginning to see that the way forward is a standardised web, rather than a competitive one. More browsers are happier to follow the standards set out by W3C. The likelihood of W3C removing the audio element is almost zero; and even if they did, the committee works so slowly there would be discussion of its removal for many years before anything actually happens.

I thin support for the <audio> element will only get more widespread, rather than revoked.

In the unlikely event, a contingency for this would be to use Flash, however. Despite the fact that I really wanted to avoid using it, as much is said in my project contract, it will be the ultimate fall back. This is also the case for if there is really no way to have Firefox play MP3 files.

All in all, I think those issues aren’t likely to crop up, and if they do I have thought out contingencies which will allow the project to be finished by the deadline.

Project Management: Issues With Flying Solo

I’m part way through reading two books; Inside RAD (US), and Paper Prototyping (US).

Both these books offer really interesting ideas about the development process of software.

Inside RAD talks about rapid application development – making a piece of software in 90 days or less. This fits my project perfectly, since I wanted to have two release iterations of ninety days each anyway (I have until April, so that works out pretty well). It’s a quick, agile method which I’m really attracted too.

Paper Prototyping deals with the novel idea of having actual paper versions of your user interface, and then getting a few actual users to “use” the application in the medium. It allows you to see what a user is expecting to happen when they “press” a certain button, or see their flow of actions when you ask them to do something. You get all this user experience research before having even written a line of code. If you need to change something, you just rub it out and sketch in a new design whilst the user is still sitting there!

The issue I’ve come across with both of these methods though is that they are tailored for a group of people working on the project. RAD requires meetings and discussion from a number of people who are experts in their role, and then a scribe to take minutes. Paper prototyping requires a person to watch the user, and give instructions, and write down their actions, and also someone to act as the “computer”.

Whilst the ethos of both these methods will definitely help my project, and lessons will be learnt, actually putting them into practice needs to tweaking or outright rewriting of the techniques.

Regardless though, I’m planning on doing some paper prototyping in early December. I’ll likely have to train a friend to be the computer, whilst I take lead. I’ll also be sticking to the two 90 day iterations.

Final year project: Web based audio player

Final year of university has arrived, and with it comes the final year project (in place of the standard dissertation other courses have).

I’ve decided to create a browser based audio player, much like Grooveshark, however the user stores all their music, and the application, on their own server. Avoiding using Flash, I want to only use the new HTML5 APIs for handling audio and web sockets.

I’m planning to be pretty open about the entire development process, and the software itself. I’ll be blogging about it on here, so this blog maybe fairly swamped with weekly (at least) updates about that.

The application will be largely free, at least until the end of development (when I have to talk to the university about who owns the rights to sell the software), so I’ll be releasing development builds as often as new features get working.

I’ll also be writing about my research into streaming audio from a server to a browser, design, and user experience.

I’ll be calling the application Sound Tiger. Not sure if that’s a permanent name, or a temporary one though.

I’ll be keeping course documents in a folder on my web site.