Finally got around to having a proper holiday in the UK and here I am at the end of it with no tan, a few kg heavier and no actual support problems to report other than a few RTFM problems. Now here I am on a 17 hour flight back to Auckland thinking about what would happen if disaster struck and I was never to be seen again!
Disasters are not really something I should be thinking about on a plane, but I am realistic enough to know there are lots of potential problems with custom software development and this is probably the biggest. My clients of course know this as I have explained it to them and while I have always ensured they have the latest copies of source code on their servers and that code is commented, it is a very complicated system and it is very likely it would be a hectic time in their IT department during the time they managed to acquire the right substitute.
So what can you do to fix this?
Well first off it isnt a problem for sole developers such as me. In one of my old jobs we had a piece of software written by IBM which theys charged an 9,000GBP annual support fee and which was very reliable until one day it mysteriously started returning the wrong data and became effectively useless. The software was written in C in 1985 by a single guy who had left the company several years previous, and while IBM had the source code for it, it relied on another executable written by a company that subsequently disapeared in 1989. So there we were in 1996 with software supported by the largest software company in the world and useless software. I got involved by analysing the binary “database” file and extracting the data as text for us to use in Excel while the legal departments on both sides wrote nasty letters to each other.
So again what can you do to fix this?
Well the first rule of custom software is dont do it, but if you do then you must ensure the company you do it with has at minimum a second development environment and programmer and good software version control. Even when you have this reassurance you must have complete autonomy over your own code and data, including old code revisions and you should have a second person or company on retainer who they are able to contact to take over the support as soon as possible and are able to audit the code for backdoors, errors etc (auditors will love you for this)
I dont pretend what I write is 100% consistant and bug free nor do I pretrend it is easy to read in some places or follows the proper standards or one that another programmer may develop in. I also admit in some cases where I was under time pressure I have made some real ugly code and some of this code I may not revisit for several years. This is the nature of the beast when you have an evolving system. All my larger systems are broken into logical units (from 100 to 5000 lines) and at times I have sometimes found it easier to remove and completely rewrite units than to try and understand them.
When an error message pops up it pays to make sure it is an error message that you put in to catch the situation, this way you can explain the problem to the user in the error message, it also means you can simply search the code base for the error message and immediately and hopefully see where the problem is (understanding it is another matter!). In Windows desktop programs every button press has a bunch of code behind it so even if you have not tested for the error you can narrow it down to a small area of source code.
So while it still nags the back of my mind I do feel my clients are as prepared as they can be and better prepared than most.
