I was recently chatting to Colm Coyle of RoIT about bespoke software and the way in which few companies now use bespoke software. I made the point that companies largely stopped commissioning bespoke software after the year 2000. We came to the conclusion that it is time they restarted.
The year 2000 forced many computer departments to do what they should have done years before - ditch their mainframes and install networks of PCs. Suddenly, when staff needed new reports, instead of having to incur weeks of Cobol programming, they could create a simple solution on a spread sheet. This has transformed the use of IT but has the process now gone too far? Colm and I think it has.
Firstly, spreadsheets are a generic tool. They can provide basic reporting but do have major limitations. Applications built around spreadsheets are rarely easy to use.
To be successful, an organisation needs a competitive advantage. It needs to do something differently and better. This will be constrained by off the shelf software. There are many opportunities from creative use of processes and customer interfacing. Organisations do not become great by following everybody else.
Spreadsheets will normally be the best way to provide a one-off solution but they are not convenient. They are also very error prone (see below). However, for any application that has to be run regularly they are inefficient. The staff costs in using a spreadsheet do need to be balanced against the cost of bespoke software. In the long term, a bespoke solution will almost always be better value.
A year or so ago, I advised a software company who are spreadsheet experts. It was interesting to say the least. Studies from academics and the European Spreadsheets Risks Interest Group (http://www.eusprig.org/) have found that most spreadsheets contain at least one error. Problems occur when rows are inserted or deleted and formulae are not adjusted properly. How do you check the results of a spreadsheet calculation? One man told me he checks by adding up the column with a calculator. You have to wonder about the point.
One thing that emerged in the run up to the year 2000 was that software had a much longer life than was realised - we discovered that an awful lot of software had its origins in the 1970s. The world of IT has changed out of recognition since then. Development costs have plummeted but I don't think some IT managers have understood this.
In the 1970s I had to add some fields to a database and change the length of the main key field. It took a team of programmers six months. A similar exercise last year took about 3 hours. In trying to remember why, I realise we didn't even have databases in those days, never mind SQL. A simple extraction and sort of data required a program. Today it's one line of SQL. Files were essentially flat, so the length and position of each field had to be specified. Incredibly, programmers rarely employed reusable code. Object orientation did not exist.
Legacy systems often had their origins in this environment which is why, even in 1999, it would cost thousands just to generate a report.
These are not the only reasons why development is cheaper. Modern programmers use integrated design environments (IDEs) which speed up the development process. Object orientated techniques have slashed debugging times. And programmers' wages have not kept pace with inflation.
Software that does exactly what a user wants is now affordable. In fact, I'm sure it can often be provided with less effort that a spreadsheet solution.