I had the tremendous privilege in the last couple days to spend time with a bunch of architects at ITARC in NYC. I’m still trying to wrap my head around it all… but that’s always the result when I spend a couple days around a bunch of people smarter than me. (Those of you who know me know that’s not too hard to accomplish… but just to drop some names, some of the people who were there – and accessible – included Grady Booch, Eric Evans, Len Bass, Roger Sessions, Angela Yochem, Bill Imnon).
One of the thoughts that struck me in the midst of Grady Booch’s keynote yesterday was that the word “legacy” tends to have a completely different connotation when dealing with code than in pretty much any other connotation.
Technically, the definition of “legacy” (from http://m-w.com) is:
something transmitted by or received from an ancestor or predecessor or from the past
Hmmm. Pretty neutral. Yet, when we talk about wanting to “leave a legacy,” it’s always with the implication that we want to leave behind some positive proof that we were here.
On the other hand, when we talk about “legacy code,” well… there’s always the implication that the code is poorly written, poorly designed, unmaintainable, etc. Michael Feathers defines legacy code as any code that isn’t under test, which is a slightly more neutral statement, yet much of his book is spent describing ways to make testable all that poorly written, poorly designed, unmaintainable code.
Now, I work for an ISV that is about to celebrate it’s 20th anniversary. We’re growing rapidly – we’ve grown from 65 employees to nearly 100 in the past 18 months. Not quite Moore’s Law growth, but getting close! We’re currently engaged in transitioning from an Access over Oracle to .NET against Oracle/SQL Server application. This is, to put it lightly, a significant undertaking.
And, while our older code base is both a legacy code base and one that could be cleaner, those are two separate issues. (Side note: any developer who tells you that their code base can’t use some cleanup isn’t paying attention!) My challenge is to separate those two concepts, and remember that the older code base is indeed a legacy from the past . But it’s a legacy in the positive sense. The product has been, and continues to be, successful in the marketplace. It allowed the company to grow to the point that we’re at today – and to be one of the best work environments I’ve heard of (and I talk to a lot of developers). It’s also a window into the past. Twenty years is a long time in this industry. Our current product has had something like 18 releases, so it’s been around for a while… the state of the art has changed dramatically. And there are just some things that can’t be done in VBA/Access (like OO programming).
After all that rambling, let me sum up. Don’t confuse the value of the legacy of the code with the value of the legacy code.