|
I get annoyed with people thinking the legacy code should be re-written just because it's old.
The 'back-end' of our flagship product is written in C, and a lot of the code is just as it was 12-14 years ago. Our front-end is MFC, which either wraps, or just calls into, the back-end code.
Although I would describe the back-end as legacy, it works perfectly, is stable, and has been tested far more than the front-end ever will be.
I know that a lot of people think that we should re-write the back-end in C++/STL/etc, but why re-write if it works? If any bugs are discovered by our customers they are always in the front-end.
The only re-writes we do are just those necessary to support a new feature in the back-end, but we keep this in C, making as little impact as possible on the existing code, so as not to introduce bugs into existing features.
For this (main) development we use VC6 as we are not looking to support anything that this doesn't give us. We use VS.NET/C# for other (new) products, and DLLs to add to our main product.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
|
|
|
|
|
I think the time to rewrite legacy code is when the effort to implement workarounds for the code's constraints exceeds the benefits.
Here's an example. We have a hardware component in our product whose software is written entirely in C. This body of code has been in continuous development for over 20 years. While the hardware's performance is currently adequate, limitations in its memory management forces constraints on us throughout the rest of the product. Redesigning the memory management in this piece of software alone would significantly enhance our ability to meet the demands of our customers.
Software Zen: delete this;
|
|
|
|
|
its gotten so bad that i can write a pong game (fully functional) in under 5 min flat!! :P around that time :P
IM PROUD TO BE A GMAIL;
|
|
|
|
|
|
lol im just using it as an example of how i don't use legacy code but i sometimes do
IM PROUD TO BE A GMAIL;
|
|
|
|
|
As a senior developer and architect
I know the problem of dev leaders and menagers to throw a way legacy code
that cost alot of money to develop and still most of it work fine
althogh it's hart to support it (there is nothing to compare between debuging c++ app to .net application )
What I usualy do is to convinst the menagers to keep the legacy code
and to build a bridge using c++/cli or c++ managed between the legacy code to a new code in .net
The advantages of this procedure are :
Most of the old features that works fine stay untauched keeping doing the good job
The new features are developed rapidly using modern tools
The mangers are happy not throwing the investment the compeny done in the past
And the developrs are happy using new technology
|
|
|
|
|
|
Or...You ride it til it dies.
|
|
|
|
|
thats a bad philosophy, it even is a bad philosophy for cars, its very dangerous if your car breaks down in the middle of the highway, it could even be fatal
IM PROUD TO BE A GMAIL;
|
|
|
|
|
Of course I meant it as a joke. Sadly enough, there are those that do this.
I like to think of code as a house. Strong foundation, proper plumbing and heating, roof for protection and locks for security, and always leave room to build on.
Visit http://www.outsourceapro.com and find out about becoming a developer in one of our development teams for some of our future consulting projects.
|
|
|
|
|
jeremypettit wrote:
I like to think of code as a house. Strong foundation, proper plumbing and heating, roof for protection and locks for security, and always leave room to build on.
In every house are many bugs 
David
|
|
|
|
|
Why does mine always feel like this[^]?
Software Zen: delete this;
|
|
|
|
|
With one exception (a command line tool) all of our current development is in Visual Studio extensibility.
That imposes certain constraints on us:
- Managed code can't be used on Visual Studio 6.0 compatible products, and we're still being asked to support them (difficult, given that the extensibility interface of Visual Studio 6.0 is extremely limited. Even basic features such as toolwindow creation and clearing of output window panes are not available through the automation interface).
- Native COM add-ins can easily support multiple versions of Visual Studio from the same binary. Even if the target platforms are limited to VS.NET 2002 onwards, managed add-ins cannot do that unless you develop in the earliest version of the IDE (VS.NET 2002, in that case). We prefer to use VS.NET 2003 for development, which adds to the case for using native code.
- Managed development using VSIP[^] is a real slog under versions of Visual Studio prior ot Whidbey. To add to that, the VSIP SDK for Visual Studio versions prior to 2003 is not publicly available, and athough we can almost certainly get it working in 2002 by examining the 2003 interfaces, that would not be possible with managed code for the same reasons as above.
- One of our add-ins is heavily multithreaded, and although using native code means we have to be very careful with memory useage and our use of kernel objects (leaks in both can be a real pig to troubleshoot) the memory footprint and speed more than make up for it.
Taking all this into account, our preferred platform is VS.NET 2003, with most development carried out in C++ using ATL 7 and WTL 7.5. Our target platforms are generally everything from Visual Studio 6.0 onwards, although experience has shown that if it works in VS 6.0, it will almost certainly also work in the abomination that is VS 5.0.
We are however planning to use C# (with NUnit or one of its derivatives) for automated testing of add-ins via the VS COM interfaces. 
Anna ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Riverblade Ltd - Software Consultancy Services
Anna's Place | Tears and Laughter
"Be yourself - not what others think you should be"
- Marcia Graesch
"Anna's just a sexy-looking lesbian tart"
- A friend, trying to wind me up. It didn't work.
|
|
|
|
|
|
Legacy code is software written some time ago that you are required to maintain because your users/customers require it. Legacy code is often maintained with an older generation of tools (Visual C++ 6, for example) or even programming language (C rather than C++). It's the type of code that you might want to rewrite using current techniques or tools, if you had the time or resources.
BTW: I think your question was an honest one; whoever down-rated your post needs to remember that our field is overrun with jargon, and not all of us know all of it.
Software Zen: delete this;
|
|
|
|
|
|
|
I don't. For me it is an external library that ships with the IDE that I use...
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
No. Our current development uses MFC throughout. Given that the majority of our application is doing multithreaded process control, we've had our doubts about using .NET. This is a decision we will probably re-evaluate once Visual Studio 2005 is released, given that Microsoft is deprecating use of MFC in its entirety.
Software Zen: delete this;
|
|
|
|
|
I am working on a rather small developmentteam at the moment
This has brought me one big advantage, we don't need to support legacy systems, since there isn't one for the solution we are building...
Normally I would spend les than 20% of my time on legacy code. The main reason is that we are a young company and we only have like 5 big solutions to work on. All in .NET
I really hope I can keep up the 20% rating, since any higher rating would mean we are degrading our thought that we should alway innovate.
WM.
What about weapons of mass-construction?
|
|
|
|
|
The need to support legacy code varies with your market.
One of our current products still supports hardware developed in the early 90's. Since some of our customers are still using it, we are required to support it. Even though that hardware is 'end-of-life'd as the parts that go into it become unavailable, newer generations of the hardware support the older data formats.
If we were to abandon support for one of these older formats, our customers would be inclined to replace our equipment with someone else's, someone more inclined to long-term support.
Software Zen: delete this;
|
|
|
|
|
But it doesn't feel like legacy: we introduce so many features, and often change so much our code (e.g., we ported, erm, rewrote, everything in C# back in 2002) that the ammount of legacy code is less than 10%.
I see dead pixels
Yes, even I am blogging now!
|
|
|
|
|
|
That depends on when it is written. People still use VC6 to write code these days...
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Bob Stanneveld wrote:
People still use VC6 to write code these days...
People still use COBOL, Fortran, BASIC etc., don't they?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
