Robert Annett - Working with Legacy Systems: A practical guide to looking after and maintaining the systems we inherit

There comes a point in everyone's IT career when they become responsible for a legacy system. This is inevitable and I call it the 'Penelope Principle.' Like the Peter Principle (where people are promoted to their level of incompetence) and the Dilbert Principle (incompetent workers are promoted to where they can do least damage management), this should be accepted and worked with rather than being fought against. It is stated thus:

"All IT workers will be promoted into a position where they become responsible for a legacy system" (The caveat is "unless the worker is so useless, they can't hold down a job and keep getting fired before this occurs." This, of course, does not apply to any reader sensible enough to buy this book. (And, yes, I do know this is the 'No True Scotsman' fallacy)).

Hopefully, you are nodding your head vigorously at this point (having bought this book, this is highly likely) and the purpose of this book is to help you deal with the situation you have found yourself in.

Why is this the case? In Chapter 1, Definition, Issues and Strategy I will spend a short while defining exactly what we mean by a 'legacy system,' but it comes down to success and longevity. The commercial IT revolution started in the 1970s when vast numbers of manual processes and physical records were placed into mainframe systems. Subsequently, these systems have not only been improved but entire new industries have been created. There are vast benefits to having information systems in electronic form and this effect was magnified by the internet revolution of the 1990s. Some systems don't add value and are scrapped, but most do and are therefore used until it becomes cost-effective to replace them.

This means there are a LOT of IT systems out there involved with every aspect and function of society. This has been happening for almost 50 years, so the number of 'old' systems outnumbers the 'new' systems many times over. In the same way that it's impossible to exist without being affected by an IT system, it's impossible to avoid legacy ones. Even if you have the world's largest group of developers and an infinite budget in a brand-new organization, you'll still have to integrate with legacy systems and eventually your own green-field projects will become legacy.

If you have a position of responsibility within an organization, you will have to deal with legacy systems.

However, the IT industry is obsessed with new technologies and new projects. University courses, books, magazines, and conferences focus on what is new and assume you always start with a clean slate. This isn't what occurs in the real world, and I hope what follows fills some of this gap. This book is not intended to present a formal methodology but is aimed at all the Penelope's out there who need a guidebook to help them with their first legacy system.

Robert Annett (robert.annett@codingthearchitecture.com)

Robert Annett has been a developer since 1995 and has worked in industries from energy management to investment banking. Much of his work has involved upgrading and migrating legacy systems, with the occasional green-field project (involving integration to legacy systems, of course). He has worked in the IT industry long enough to realize that all successful systems become legacy eventually.