Monday, June 12, 2006

Legacy Systems

I've just had an argument with my IT Coordinator about legacy systems in our company. We've got several islands of automation created with FoxPro and Visual Basic 6.0.

The argument began when he wanted me to help another coleage to debug (or perhaps "clean" the mess of) the old program because of some silly problems.

Personally, I don't like FoxPro very much. Other than it is an old and dying language, I don't see a bright future out of it. And you want me to learn the dying dinasour language? I don't think so.

Some transactions were literally messed up and the IT department is required to get into the database and change some values (like from True to False) in some of it fields, and in often cases, deleting records.

I simply can't understand why such feature was not included into the system during development. We can't just simply debug when a problem occurs, can we? It won't solve the problem at all.

"I'm not gonna learn some dying language that gives me no future... Besides, we're implementing SAP, why would we need this (buggy) system? We're not gonna use it in 2-3 months."

"Don't get things wrong... even SAP system is up, the legacy system is still gonna run. And probably for the next 10 years..."

"Oh.. really? So u expect us (the IT department) to debug and clean the mess everytime problem occurs for the next 10 years? Should I quit my job then?"

Eventually, the IT manager came and rescued the day. He concluded that if we really want to keep the old system, we should probably consider putting it into a more sophisticated environment; redoing it in VB for example.

And there goes another day.. ^_^

No comments: