Between a rock and a hard place...
-
Recently, a need for plant floor data arose that left me in a quandry: do I revamp the VB 6 application that was originally written to process this data (pre .NET) or, do I retool an existing .NET service to process this data? On the surface it seemed like a no-brainer: use the .NET service and don't resurrect the legacy application... but, the caveat was the time frame: managment wanted the data the day before the request... I worked through lunch and retooled the .NET service; it looks like its going to work. What have you been pressed to do that required a similar decision: legacy or current? What decision did you make and why? Tim
-
Recently, a need for plant floor data arose that left me in a quandry: do I revamp the VB 6 application that was originally written to process this data (pre .NET) or, do I retool an existing .NET service to process this data? On the surface it seemed like a no-brainer: use the .NET service and don't resurrect the legacy application... but, the caveat was the time frame: managment wanted the data the day before the request... I worked through lunch and retooled the .NET service; it looks like its going to work. What have you been pressed to do that required a similar decision: legacy or current? What decision did you make and why? Tim
I'm in a position where no one pressures me on anything but in general it's a pretty easy decision based on a best guess as to how much change it's going to require in future. If I think an app is going to need pretty much *any* change in future then I go current. I find few things in life as soul sucking these days as having to wrap my mind around old C++ code. I'm too used to getting real world things done quickly now with .net to go back to plodding along in c++.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
-
Recently, a need for plant floor data arose that left me in a quandry: do I revamp the VB 6 application that was originally written to process this data (pre .NET) or, do I retool an existing .NET service to process this data? On the surface it seemed like a no-brainer: use the .NET service and don't resurrect the legacy application... but, the caveat was the time frame: managment wanted the data the day before the request... I worked through lunch and retooled the .NET service; it looks like its going to work. What have you been pressed to do that required a similar decision: legacy or current? What decision did you make and why? Tim
Never resurrect the dead. Especially not if it's dead VB6.
-
Recently, a need for plant floor data arose that left me in a quandry: do I revamp the VB 6 application that was originally written to process this data (pre .NET) or, do I retool an existing .NET service to process this data? On the surface it seemed like a no-brainer: use the .NET service and don't resurrect the legacy application... but, the caveat was the time frame: managment wanted the data the day before the request... I worked through lunch and retooled the .NET service; it looks like its going to work. What have you been pressed to do that required a similar decision: legacy or current? What decision did you make and why? Tim
Sometimes a legacy app is written very well. I have seen many legacy systems outperform their modern counterparts. The real question is, how much technical debt will this action occur? The only reason I would rewrite a legacy app is if I didn't have access to the compiler or it was not up to the task at hand, or if it was so unreliable that it really couldn't perform reliably.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
Recently, a need for plant floor data arose that left me in a quandry: do I revamp the VB 6 application that was originally written to process this data (pre .NET) or, do I retool an existing .NET service to process this data? On the surface it seemed like a no-brainer: use the .NET service and don't resurrect the legacy application... but, the caveat was the time frame: managment wanted the data the day before the request... I worked through lunch and retooled the .NET service; it looks like its going to work. What have you been pressed to do that required a similar decision: legacy or current? What decision did you make and why? Tim
I am supporting asp and vb :( as well as developing new on .NET It is a constant battle as to whether to update the oldie or create new one. If the change is fairly simple and quick then I update the asp pages. There is no simple silver bullet. I have been trying to convince everyone to drop dead the asp and convert the whole thing to .NET. There is a general understanding of the need, but the fear always out weights (not on my part). So slowly but surly I am chipping few things here and there, before they know it, it will be all converted ;)
Yusuf
-
Recently, a need for plant floor data arose that left me in a quandry: do I revamp the VB 6 application that was originally written to process this data (pre .NET) or, do I retool an existing .NET service to process this data? On the surface it seemed like a no-brainer: use the .NET service and don't resurrect the legacy application... but, the caveat was the time frame: managment wanted the data the day before the request... I worked through lunch and retooled the .NET service; it looks like its going to work. What have you been pressed to do that required a similar decision: legacy or current? What decision did you make and why? Tim
Typically, I avoid re-writing a working app. If new functionality is needed then I try to avoid re-write by providing additional services with modern tools if it is not to convoluted.
Sovereign ingredient for a happy marriage: Pay cash or do without. Interest charges not only eat up a household budget; awareness of debt eats up domestic felicity. --Lazarus Long
-
Recently, a need for plant floor data arose that left me in a quandry: do I revamp the VB 6 application that was originally written to process this data (pre .NET) or, do I retool an existing .NET service to process this data? On the surface it seemed like a no-brainer: use the .NET service and don't resurrect the legacy application... but, the caveat was the time frame: managment wanted the data the day before the request... I worked through lunch and retooled the .NET service; it looks like its going to work. What have you been pressed to do that required a similar decision: legacy or current? What decision did you make and why? Tim
Here's my list: If you can redo the task in the old system fast enough that it will satisfy the requirements then do it. Why buy a new hammer? If you feel that eventually you will want the app in .NET and will have more time later to do, then redo the old if it will be faster and then port the app at your leisure later. If you will not have time later to do the port but need the app in .NET then you'll have to bite the bullet and port.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
Recently, a need for plant floor data arose that left me in a quandry: do I revamp the VB 6 application that was originally written to process this data (pre .NET) or, do I retool an existing .NET service to process this data? On the surface it seemed like a no-brainer: use the .NET service and don't resurrect the legacy application... but, the caveat was the time frame: managment wanted the data the day before the request... I worked through lunch and retooled the .NET service; it looks like its going to work. What have you been pressed to do that required a similar decision: legacy or current? What decision did you make and why? Tim