Although I would support your decision to remain with a legacy system, especially when you have the technical people to continue servicing it, the scare for the company is if you should leave them, much of the knowledge is lost with your departure, and hence the company will probably be up s_-t creek!

Now many people still know 30 year old programming languages, and the ones that do, I am sure are commanding very large salaries.

Often there is a knee-jerk reaction that if something is more than a few years old then automatically it follows that it cannot be any good. I agree with you that this is a wrong assumption. - It sounds as if your ERP system was developed and enhanced well over the years to accomodate changing business requirements.

Your concern though about staff being suprised about the lack of mouse usage is something to watch for. Increasingly, user exepctations of systems have been moulded by the Windows environment and this can lead to frustration if users feel the system is not working for them. In some cases users may abandon the system because ‘Excel is easier to use’. If this happens then there are worries of data integrity, duplication, or completeness.

I suppose it is likely that developers, especially new ones, prefer the modern languages like Java, C#, Ruby and the like - as a returning student at Uni this is very clear as students look confused when I mention that I develop in Cobol - mind you I’m not compleletely old school and I do develop in C# and Java too!

That said, we have never found a shortage of Cobol developers - this was demonstrated effectively during the Year 2000 crisis when our development team reached the heady hights of 7 programmers and we were offered many many more via agencies!

As Martin points out business knowledge is a major contributing factor - many of our staff have been with the company in its various guises as long as I have (some even longer!) and they all have valuable information in their heads and are familiar with the way the software works so they can get new staff up to speed (or is that down to speed?) very quickly.

As Moshe rightly highlights with users sometimes saying ‘Excel is easier to use’ - Spreadsheets are definitely something that we often battle with especially as it is so easy to start collecting data using them. I have always been of the view that spreadsheets should complement the core system and be used for analysis of information - not for data collection.

The opposing view is often that a spreadsheet can be set up far quicker than a program can be analysed, designed, written and tested. This worries me even more as often spreadsheets are setup as freeform entities and are often modified or amended in adhoc fashions with little regard to any analysis, design or testing.

Many a time spreadsheets have been deemed essential by a user or users only to find that when they move on or change jobs these spreadsheets are simply archived and never referred to again!

We have looked at adding a GUI front-end in the past using either thin-client cobol or screen scraping technologies but with so many other developments on the list it never really gets the attention it should (especially as something like the front end affects every 2000+ program in the system).

Bravo, Jason!

As one who has worked with “legacy” applications since 1978 and has been involved with the development of COBOL programming tools for 21 years, I can say that your commentary is 100% accurate.

Too often, people dismiss older technologies as being “obsolete” when in fact, the word “old” actually implies that the technology is both proven technology as well as useful technology…otherwise it would never have gotten old in the first place. It would have lived a very short life and disappeared from existence.

I am also amazed at IT shops which blindly plunge into some of the newer technologies without first putting the technologies to the test in order to ensure that they will stand up to the rigors of REAL data processing requirements.

There’s nothing wrong with using a mix of old and new technologies as long as they do the job and are maintainable over the course of a reasonable span of time.

IT Managers must regard business applications as corporate assets which should be amortized across the longest period of time possible in order to ensure their cost-effectiveness.

Re-writing applications every two years for the sole purpose of using the “language du jour” is a terrible waste of corporate resources unless it can be proven that the corporation will benefit financially from the re-write.

Again…kudos to you for speaking the truth!

There’s plenty of old stuff out there and tellingly it’s banks, defense, HMG,… who use it. Not because they are stick in the muds but because they can’t afford for stuff to fail so they don’t change what ain’t broke.
I develop terminal emulation software so I know! I always say old s/w is good because it is tested but bad because the UI is outdated. Hence grafting a new UI on old s/w is the best of both. You can do a lot with terminal emulation on thin clients or PC’s but I’m not a salesman
http://www.itpro.co.uk/blogs/davef/

COBOL was, way before spreadsheets, databases and SQL, the language of business programming, and the lack of foresight that led to millenium bugged programming cannot be blamed on the language, other than perhaps the lack of a standard and robust data type for dates.

I can remember other langauges that had flawed date formats, even the Unix 32 bit date format is flawed, an issue that will already be hit by a 30 year term from now.

I think outsourcing is just every where and not only in one country or region

http://www.outsourcewebsite.com

Nice blog,thank you.