Derek Longmuir presented ThoughtWorks QTB on working with legacy systems. You can see the video and slides on InfoQ.

I like the definition given by Michael Feathers:

Legacy code is simply code without tests.

Legacy Systems have Value. They are usually business critical and feature rich. They may even be stable and reliable (YMMV). Hint: in the MindMap below, start at 3 o’clock and go clockwise.

Why change from a legacy system? There are number of good reasons: obsolete technology, can’t add features, system is fragile.

This is an important problem since most systems we have 10% of the effort to build and 90% effort to maintain. So to manage costs, we need maintainable systems.

What to do?  Traditional approaches such as Big Bang (think explosion) and wrapping/hiding legacy systems rarely achieve business objectives.

Do a system health check. Look at the code. Get complexity measures. Look at test code ratio. What state is the system in?

Before getting started, there are some tools that you will need for basic technical hygiene. The equivalent of brushing and flossing your teeth is test and build automation.

How to tackle this?

With the Strangler approach, the goal is to strangle the existing application by building a new system that runs in parallel. The idea is to put a new interface in place and begin migrating the functionality in a piecewise fashion. This approach takes a lot of effort and makes sense when there is no hope for the existing code base.

The Phased approach is about rehabilitating the system piece by piece. How do you eat an elephant? One bite at a time.

Strangely, there was no mention of the bible on this topic: Working Effectively with Legacy Code by Michael Feathers. This book is a must-read on this topic. As is Refactoring, Refactoring to Patterns, and Clean Code.

Last fall, I had the opportunity to hear Ross Pettit and Jane Robart present at the ThoughtWork QTB in Toronto.  You can see the full presentation and slides on InfoQ. (Hint: if you are in Toronto, there is a talk on Legacy Systems coming up on Friday, Feb 5th).

The most memorable phrase from the presentation is: All IT projects are a voyage of discovery. This seemed to be a very salient way to express learning and communication are key.  Check out my drawing of a boat

So the talk is all about governance - how do we ensure that our projects are succeeding? There really isn’t very much in there about the PMO’s role and for that matter about Agile.  Still some very interesting points…

One aspect of governance is making sure we have the right people in the right roles since IT is a people business. The reality is that most managers tend to stick with people even if they aren’t working out in that role. One idea is to use net promoter score: would you recommend a colleage for another project?

Another key idea is independent steering committees. In many cases the stakeholders (usually senior management) are on the steering committee for a project that they are sponsoring. Well, you know what happens when there is a conflict of interest. I’ve seen it happen first hand recently and it wasn’t pretty.

Finally, good steering committees have a breadth of talent that can function as a team to dig into the project data and ask tough questions. They need the right set of lenses to view the project from different perspectives – technical, financial, customer, etc.

Overall the talk was quite informative since I have seen lot’s of room for improving governance at most organizations I have worked at.