The Institution of Analysts and Programmers

As a software developer of the best part of 40 years, I have developed everything from games on 1970’s computers, through to largescale financial systems and everything in between.

The consistent things I have seen are employers and project managers wanting it all done yesterday and ahead of budget. This of course is understandable but I question the long term effect on the business and on occassion the sanity of the developers left to pick up the mess.

Writing a computer programme is like building a house, quite often a single programme will be part of a far larger suite of programmes to run a series of predesignated but interconnected tasks.

Within a company several sets of unrelated suites of programmes will run, sales, purchasing, accounting, building management, heating controllers etc.

So coding is a lot like bricklaying, you are building a foundation that will serve the company well. The suites of programmes are like a street of houses and the company is the city.

This is all fine when it is first built, like a house there may be teething issues and the builder has to fix a leak or some other error, just as wehn a programme when it is run may uncover a bug or two after it has gone life, even after testing.

Now later down the line, the code like a house may show signs of wear, amendements have been made and the programme no longer does what it was designed for, similar to my own house where we had more children, converted the loft and added an extension. Later my children left home just as the computer programme may no longer actually serve it’s original function because that bit of business is no longer done.

From experience a few years ago I had to write new code and amend existing code to process the Child Trust Fund a Government initiative to get parents saving for thier children. Lots of work for the team I was with at the time. Change of government a few years later and the scheme was scrapped. So now this code is still embedded in all the systems that are running every day and because it is easier to leave it in than remove the code, the whole suite of programmes is probably still running today.

I worked for an insurance software company for a few years managing one of their insurance quoting products. Hundreds of bugs in the bug folder (yes on paper) and over a 12 month period I go the bugs down too a couple of dozen. One thing I noticed was the time it took to quote for a person (who would be sat in a Independant Financial Advisor IFA) over 2 mintes for 60 individual companies quotes. By now I had a good idea of the system and one day printed out the main quote code, laid it out and analysed it. After a day or so I realised that a lot of duplicate code was present and I also could see that if I rewrote certain chunks of the code it would a) read better b) be more logical. out of 85 pages of code, I removed 30 pages. When the programme was run the next time the quotes took 22 seconds.

So what do we get from this?

Well as a product manager I had the authority to do as I wished with the code. I was able to prioritize and allocate resources. I did what a modern house builder does, I went in knocked down the walls and made a more usable space. I removed everything that was extraneous and I could have rewritten the code from scratch.

Like a City, sometimes when a district or street becomes dilapadated, developers will come in and flatten everything and rebuild using the latest more effecient building techniques. Sometimes (probably more often) comapnies should look at thier software real estate and allow the developers the time to remove the junck, rewrite if neccesary, even a whole suite.

Why?

Code that has been continuely amended over a long period of time is like a house that has been maintained for years, that is full of cracks, damp, floorboards that creak as they gently rot under your feet.

It needs to be repaired, or better still clear it out and rewriite. It will be easier to read, easier to support and probably run more effeciently, faster code means cost savings.

In addition you could take the opertunity to upgrade to a newer coding platform. There are still billions of billions of lines of COBOL and Visual Basic out there. I know it still runs but modern languages running on 64 bit platforms generally offer but functionality than those languages that come before.

As a devote of VB6, I took the plunge and had a programme o convert much of that software estate to .NET, I also found about 30% of the programs we had, were no longer used, so were not converted.

As a developer who did overnight support, the last thing I wanted was to trace through code at 3am trying to find a bug. Then having to patch it and finding the next day my manager saying leave it in, more damage to the system.

As a manager, I could see that an expense now, may seem unneccesary but in the long term would save money that outways the cost and of course your software teams sanity.