Nice and catchy title, isn't it? First a disclaimer: I've never got the chance to try this in real life.
I was having lunch with a colleague working in projects orbiting an ancient mainframe-system originally written in 1980's (we were having Nepalese food btw, my favorite). The problems they were having in his company are very common. The legacy-system was originally written by a small team - probably less than 10 people - and through the years the size and role of the system grew to something like a CRM. Yes, this must sound very familiar.
Now the people who wrote the system are closing 60 years of age and are planning retirement. The system will probably die as the last original developer leaves the company. How do you cope with a situation like this?
The most common solution to this problem is to buy a very expensive CRM-software and start a small integration-project that aims to replace the old system as-is. Usually about two years later you have an enormous, failing integration-project in your hands and instead of one, you now have two legacy-systems and even the original one is now burning more man-hours than before because "slight" modifications were necessary.
So how would I do it? Here's how:
I'd assemble a small team with the best developers I could get my hands on. I'd provide them with the best tools available and seat them in a comfortable office with free drinks and, most importantly, the original developers and experts with the knowledge of the legacy system. I'd start small, something like reproducing one core function of the old system. The developers of the new system could ask 100 times a day how some minor detail works. The new team could write acceptance tests from what they've learned of the old system.
Then maybe a year later the old and the new system could start to run side-by-side, some transactions of the old one routed to the new one. This is what is done with plants (hardening) so why not with software. One function at a time the new system would then replace the old one and grow to a complete system with all the functionality of the legacy software working as it did before, the difference between them being that the new one is done with (hopefully) a modern, flexible and light architecture that enables it to grow along with new business requirements. And what's even more important is that you now have a new team of people who know the new legacy system inside-out.
I wonder if it was Brooks again who has said that there are only two kinds of software-projects: ones that fail and legacy nightmares. As bleak as that sounds, in my opinion, a legacy-system is a nightmare usually only after the original developers of the system are no longer available. So after the system is done, make sure the developers have no reason to change jobs! Do not disassemble the team!
The lesson here, in my opinion, is that large systems cannot be built. They are grown instead by a long-living team. Anything else and you're probably going to fail.
My next blog will not have anything to do with legacy-architecture, I promise :)
I have problems remembering how code I wrote 1-5yrs ago worked.
ReplyDeleteI wonder if 60yr old granpas remember what they wrote 10-30 years ago =)
There's a fundamental flaw in your thinking. The new system should be designed to support optimized business process and not to imitate the old system. Also evolutionary development becomes increasingly more difficult after the system goes live.
ReplyDeleteGood point and I agree. I do not thing these two goals are mutually exclusive though.
ReplyDeleteOn the other hand, I've rarely if ever seen a successful transition where the old legacy systems are fully replaced at the same time that the business processes are optimized. If there are public references for this, I'd love to see.
So maybe this could be done in two steps. First implementing a new, more adaptive and modern system that does what the old system does and after that optimize the processes.
And I also agree that evolutionary development is more difficult after going live, but personally I think its usually more related to the original development team being dismissed after go-live and the project going to a much more stiff operation model. It doesn't have to work like this and many modern companies also operate in a way that they can push releases out often and with much less ceremony.