The Value of Legacy Systems
Articles and commentary to refute the misguided notion that Legacy Systems are somehow bad. Survival and continual enhancement for ten years, twenty years, thirty years, or even more is evidence of a resilience and robust nature, not evidence that the systems are too difficult to change. In fact, the phrase Legacy Systems could almost be used interchangeably with Mission Critical Systems.
Title
|
Description
|
|---|---|
| Debunking Myths about Legacy Systems - part 1 of 3 | In this first of a three part series, IT veteran Derek Britton considers some of the criticisms of Legacy Systems and finds them sorely lacking, misleading, fraudulent, or all of the above. |
| Debunking Myths about Legacy Systems - part 2 of 3 | In this second part of a three part series, Derek Britton examines what is really important: the value that a Legacy System brings to its organization today and tomorrow, not the age of the system. |
| Debunking Myths about Legacy Systems - part 3 of 3 | In this third of a three part series, Derek Britton sets forth some strategies on how organizations can continue to harness the power inherent in their mission critical Legacy Systems, and in a very cost effective manner. |
| Rewrite in place - don't rewrite from scratch! | A great article from Joel Spolsky, the Joel on Software blogger. Take this succinct quote to heart: "The single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch." Spolsky mentions several techniques that can be used to re-architect and re-write a complex software application in place: refactoring, consolidating duplicate code, repackaging code fragments into the "correct" module, improving interfaces, and the like. One observation that he did not make but should have: a large application of several million lines of code and thousands of modules often, even usually, manifests behavior where there is a non-uniform distribution of latent defects. In other words, there will be some modules that for whatever reason, show a much greater tendency to manifest bugs than other modules. If you have a defect tracking system, or even if you only document with comments in the program all the routine maintenance you had to do, you can identify those most problematic modules and rewrite them first. |