Panel Living With Legacy: Love It or Leave It? Steve Berzcuk (Moderator) Iron Mountain Michael Feathers Object Mentor Steven Fraser QUALCOMM Dennis Mancl Lucent Technologies Bill Opdyke North Central College ABSTRACT As the volume of legacy software grows, how have we grown in our ability to leverage this legacy – or, for that matter, is it worth the effort? Is legacy software a hoard of useful information and behavior – or is it a ball and chain, something you should cut loose if you want to make progress? Legacy constraints often seem immense and burdensome – but, do they always need to be? Is object-oriented legacy software spaghetti code – or is it more like ravioli? Do agile methods embrace or reject the use of the legacy? Categories & Subject Descriptors: D.2 Software Engineering D.2.10 Design General Terms: Design, Economics, Performance Keywords: Software legacy, off-shore development, ROI 1. Steve Berczuk (moderator), steve@berczuk.com Steve Berczuk is a consultant, software developer and author. He has been involved in OO development since 1989 and is on staff at Iron Mountain working on their digital archives application. Steve is a member of the ACM, the IEEE, and holds a BSc in EE from MIT and a MSc in Operations Research from Stanford. 2. Michael Feathers, mfeathers@objectmentor.com Legacy code seems to be the one thing that we don’t like to talk about in the industry. Most of us would rather not think about it; we’d rather pretend that it doesn’t exist. We go to conferences and learn about architecture, the latest design techniques and latest implementation technologies, and we resolve to use them in our next project, hoping that it will arrive soon, but knowing in our hearts that we will be working on the same brittle systems for the foreseeable future. In the 1980s and 1990s it seemed that most IT organizations were in an arms race. A lot of money was spent on system replacement. But, the business environment has changed. Today, organizations often avoid rewriting software unless they see a clear competitive advantage. They are choosing to fund continued development in existing code, and most of the code that exists today won’t be replaced any time soon. As an industry, we have to adjust ourselves to this change and consider what it means to us. Is it enough for students to work on a series of small projects in school, each built from scratch, only to be confronted with hundreds of thousands of lines of existing code on their first day at work? Are we actively seeking ways of evolving design in existing code and confronting the reality that most of us have in our working environment? Can we reflect on languages, environments, and tools and consider how we can improve our current projects so that we can leave a better legacy for the next generation of developers? I think we can, but these are large shifts in emphasis. Fortunately, although our discipline is young, I think we are in a good position to deal with these problems. But we have to recognize legacy as the new status quo and take up the challenge of dealing with it constructively. Michael Feathers works for Object Mentor, Inc. He is the author of the book Working Effectively with Legacy Code. Michael cur- rently provides training and mentoring in Test-Driven Develop- ment (TDD), Refactoring, OO Design, Java, C#, C++, and Ex- treme Programming (XP). Michael is the original author of CppUnit, a C++ port of the JUnit testing framework, and FitCpp, a C++ port of the FIT integrated-testing framework. 3. Steven Fraser, sdfraser@acm.org When it comes to legacies, it is really a question of “Use it – or Lose It.” Personally, I’d be worried if any software professional expounded on their love for any sort of legacy! In truth, the ques- tion posed by this panel has more to do with evaluating and pre- dicting the value of software than dealing with the nuts and bolts of software assembly and maintenance. Looking beyond software, legacy attributes include software professionals, competitors, customers, regulators, and the global situation. First and foremost, a legacy is about “success,” since no software system grows to any (legacy) age if it does not satisfy some meas- ures of value. Many legacies enable a rich feature platform which provides a competitive edge achieved by incremental effort that amplifies previous work. What are the situations where one would desire to “Lose it or leave it?” In my humble opinion, there are two driving forces – one related to performance and the second to the market. In terms of performance, if incremental effort costs more than the return on investment, this is a bad sign. Similarly, if the marketplace changes, perhaps due to evolutions in technology and customer desires, then performance doesn’t really matter. A better mouse trap with more features doesn’t demonstrate added value if there are no mice. If the marketplace and technology disruption (as introduced by Clayton Christensen) are the key drivers then the legacy will likely fade away and no one will notice that it’s gone – aside from design and support staff looking for new opportunities and a few trailing edge customers. Copyright is held by the author(s)/owner(s). OOPSLA’05, October 16–20, 2005, San Diego, California, USA. ACM 1-59593-193-7/05/0010. 387