David Morgan, the IAP’s President, discusses his experience of a too-common system development problem.
I’m primarily a project manager. It’s the job I’ve been doing – together with some business analysis – for the better part of twenty years, on the Indian sub-continent and in the UK. So I’ve never really seen myself as a programmer. Oh, I learnt BASIC in the 80s, like many people, as a hobby. And I was introduced to Pascal and COBOL at university. I’ve used ADA briefly and decoded someone else’s FORTRAN. But if I want to get a fast result, I’m more likely to sit some VBA code behind an Excel workbook than develop an application from scratch, which, of course, I wouldn’t normally be expected to do. In practice, the quick and dirty solution is quite often a necessary evil, perhaps to show a client what an application will look like. The problem arises when other people want to use your database or spreadsheet in unintended ways. I have three examples. Judge for yourself as to whether there are business risks involved in not following proper development processes.
In the late 90s I took a contract with a major utility in the run-up to deregulation. They were tailoring a customer billing application ready for their entry into the electricity market. One of my roles was to manage the configuration of the security application used to control access, dependent on user, to the controls of the application. Every control and menu item could be switched on or off. There were hundreds of them, each having 1of 5 user settings and 2 states. I needed to interrogate the application, find out what all of the settings were, compare this against the documentation and ensure they were correct. I also had to record the settings required by particular tests and again compare them with the actual settings. The task itself is fairly trivial, just comparing two sets of data at a time. I chose Approach to create a simple database that would easily allow me to look at the data and carry out checks on it. Nothing to it at this stage and no problem. It was a quick tool I’d created for my own use. I was then obliged to let someone else have a copy so that they could carry out some limited tasks. No risk there I thought. My contract ended, I left the company and thought no more about my Approach database. When my next contract ended, I used my networking skills (personal not technical) to see if there was a suitable vacancy at the previous employer. As luck would have it there was. They needed project office support on a follow-on project and my previous experience meant I was ideal for the job. I was soon back among old friends and quickly up to speed. One old friend I hadn’t counted on meeting though was my Approach database. Clearly word had got round that I was back because within two weeks I started getting support calls for it.
Another contract and another company. This time, someone else had written an application. The company had needed to gather information about sales leads picked up by field staff who were not salesmen. They needed to record sufficient information about the prospective client and then to feed this into another application, which checked if the prospective customer already had an account. This application had to do a small amount of preprocessing and then pass the data to the main application. As a stopgap, a series of Perl scripts were written to handle leads sent to an email address set up for the purpose. The employee creating the application had some skills in Perl but not sufficient for a robust, well-designed application. However, it worked and ‘would do’ until there was time to set up a project to do the job properly. Some years later, I was involved as project manager in handling the IT for a project which had to interface to the sales lead application. It has now become part of a business critical process.
In 1999, a company employee wrote an application in Paradox to interface with Sage accounting software. He was not a developer or programmer, merely someone who had gained sufficient skills, from his own interest, to produce an application to service a particular need. Nine years later, I’m working on a project to migrate this application from an old unsupported server to a nice new one. Not because the application keeps falling over but because the server does. The difficulty is that there is no-one in the company with sufficient understanding of the application to maintain it nor to assist in solving the problems that arose when we tried to migrate it. So expensive external consultants had to provide assistance. Fortunately the migration is now almost complete. The application is expected to remain in use for at least another 6-9 months until its functionality is incorporated into a more stable suite.
I’m not suggesting that these applications were necessarily badly written or that they didn’t fulfil the requirements of the businesses using them. My concern is that they are, by their very nature, poorly documented, and not included in any sort of support programme. Once the developer has moved on, the business is left with no-one who understands the application. It’s unlikely that they’ve been optimised at all. And yet this kind of application can end up as part of a business-critical process.
What can we do about this? Frederick Brooks, in his seminal ‘The Mythical Man-Month: Essays on Software Engineering’ devoted an entire chapter to the title ‘Plan to Throw One Away’. That’s what should have been done in these cases. They’re prototypes; first drafts. But while they’re working, as I’ve demonstrated, human nature dictates that they’ll go on being used. One answer is allow them only a limited lifespan, say by restricting access via a date-dependent password. If you’ve got other ideas and experiences, let us know so we can share them with the rest of the developer community.
[Interesting project or development? Let us know at eo@iap.org.uk!]
