ROI is often used to mean “return on investment”. It is a concept I often think about when working with computers – is it quicker to do things by hand or to invest the time in writing a script to handle them automatically. An example of where I’m presently pondering it is the music library I am developing for the training band.

I’ve now got just under 20 pieces added to it, which is more than enough to cover our concert at the end of March. However each one takes about 15 minutes by the time I have copied the source files, renamed them to fit my schema and inserted suitable entries in the database which generates the web pages to give each player the files they need. I’m using a little bit of programming magic, otherwise copying, renaming and inserting each file reference could take twice as long for the fuller sets of pieces but, if I could get it down to 2-3 minutes that would make it worth investing 2-3 hours of development time as I’ve got over 30 pieces still to go.

I’ll be a bit more conservative on my sums. Let’s say that I can manage to save 10 minutes per piece. That means each hour I put in is the equivalent of 6 songs from the expected time saving. I’m pretty sure it will take me more than an hour to fully work out but that should be enough to figure out whether I’m on track or not so, given the 30 songs backlog, it is definitely worth a punt. What I will need to do though is figure out where I’ve got to after investing the first chunk of time and then I can reassess whether I’m onto a winner or if I’m likely to lose out. That said, I’ve also got in mind that I might eventually add another 200-300 songs from the other band’s combined pads so even a relatively modest time gain might be worth it for the bigger picture.

Anyway, that’s how, from a programming perspective, I think about return on investment.