In a litter I wrote to a workmate about the future development plan for a legacy product, I present some viewpoints as following.
==================
Hi John
Among recent discussions about the direction of WinVictory, having things redesigned and rewritten was never discussed. I know redeveloping anything is risky, or at least sound risky to management and accounting.
There are some industry statistics about redeveloping legacy applications, though I don't quite remember the source. It is not uncommon. A fresh example I just got is about Google Earth formerly known Keyhole. According to the Avibar, the co-founder of Keyhole, the code base has been rewritten several times.
http://www.realityprime.com/articles/how-google-earth-really-works
I don't believe the programmers in Keyhole or Google have bad habit of software engineering, I tend to think they had to rewrite codes because the requirements got changed dramatically. The founders might not ever dream that the program can reach such large audiences of different levels of users. Fast expansion of broadband, evolution of graphic cards, porting things to Linux and different business models might not be in the early stages of requirement analysis and planning, and refactoring legacy codes may not necessarily always be able to adapt new requirements and take advantages of new conditions. Well written codes do not necessarily have unlimited maintainability, flexibility and extensibility. They don't need to be ashamed of, as no one in Keyhole could predict such changes. This is my interpretation for why they rewrote the code base.
Quoted from the book Code Complete (Chapter 3, Measure Twice, Cut Once: Upstream Prerequisites). As with building construction, much of the success of failure of the project has already been determined before construction begins. If the foundation hasn't been laid well or the planning is inadequate, the best you can do during construction is to keep damage to a minimum.
Sometimes I had to admire previous programmers having tons of memory to remember things and capacity to handle such complicated codes.
Now the construction of WinVictory has long been "finished", and what's the best we can do for maintenance? Or upgrading? Or migrating?
No matter which direction to go for WinVictory, using Win32 or dot Net assembly, the job is still maintenance, more exactly hacking codes which is what we have been doing in the last few years. I really have low expectation on any technical attempts of moving forward or backward.
Rewriting (read legacy codes and user manuals to guess requirement) to get "WinVictory Vista" is risky regarding to costs but predictable, and migrating codes forward or backward sound not so risky to costs, but may likely be unpredictable. Almost all industry statistics showed maintenance is much more expensive in average than building.
After all, it is about vision and direction which are not clear.
Regards
Andy
