ptg Praise for Managing Software Debt “If you work in technology, you’re probably familiar with terms like ‘technical debt.’ The meta- phor seems easy, but using it to influence change can be remarkably hard. To do that, you’re going to want to present options to decision makers, backed up by evidence. I’ve been impressed watching Chris Sterling research and refine his work in just this area for several years, and I’m pleased to see him release it as a book. If you want to go beyond clichés to talk about how to deal with the problem of software debt, this is the seminal work in the field—and it’s also the book for you.” —Matthew Heusser, Software Process Naturalist “Inertia: It’s what restricts change and leads to a cost of making a change or starting a change after a period of no investment or maintenance. This book explains in great detail what the dif- ferent types of debt are that lead to inertia and, ultimately, to a cost to the business in manag- ing software maintenance and development. The richness of explanation in this book of how to manage the virtual debt that every business incurs is unmatched. Every business-focused CIO, enterprise architect, software architect, or project manager should have a copy.” —Colin Renouf, Enterprise Architect “Software debt is an important concept and Sterling does a sterling job of explaining what it is, why it is bad, and how to avoid it. A healthy dose of theory sprinkled with lots of pragmatic examples.” —Roger Sessions, CTO, ObjectWatch (objectwatch.com) “Chris Sterling’s experience in Agile architecture and his focus on software debt make this book a must-read for architects and engineers on Agile teams.” —Jan Bosch, VP Engineering Process, Intuit “This book offers highlights and shortcomings of managing inherited software code and the debts that come with quality software. The author offers a unique perspective on dealing with software development issues. A must-read for all software developers.” —Leyna Cotran, Institute for Software Research, University of California, Irvine “The vital importance of rapid feedback to the software process is a fundamental premise of modern software methods. When such feedback is quantified in the form of software debt, the software process becomes most effective. Chris Sterling’s book holds the details you need to know in order to quantify the debt and pay it back. Moreover, it will teach you how to avoid debt in the first place.” —Israel Gat, The Agile Executive (theagileexecutive.com and on Twitter at @agile_exec) “This book represents a wonderful opportunity for a larger community to take advantage of Chris’s many years of experience and his innovative approaches to Agile architecture and con- tinuous quality. . . . His book distills many of his principles and techniques into practical guidelines, and he manages to convey very powerful ideas in accessible prose, despite the inher- ent complexity of architecture and technical debt. . . . Chris’s book will help architects, leaders, and teams see their way to better systems and better organizational performance.” —Evan Campbell, Founder of Chinook Software Consulting This page intentionally left blank M S D ANAGING OFTWARE EBT The Agile Software Development Series Alistair Cockburn and Jim Highsmith, Series Editors Visit informit.com/agileseries for a complete list of available publications. Agile software development centers on four values, which are identified in the Agile Alliance’s Manifesto: 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan The development of Agile software requires innovation and responsiveness, based on generating and sharing knowledge within a development team and with the customer. Agile software developers draw on the strengths of customers, users, and developers to find just enough process to balance quality and agility. The books in The Agile Software Development Series focus on sharing the experienc- es of such Agile developers. Individual books address individual techniques (such as Use Cases), group techniques (such as collaborative decision making), and proven solutions to different problems from a variety of organizational cultures. The result is a core of Agile best practices that will enrich your experiences and improve your work. M S D ANAGING OFTWARE EBT B I C UILDING FOR NEVITABLE HANGE Chris Sterling With contributions from Brent Barton Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omis- sions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. Cover photograph reused with the permission of Earl A. Everett. The quotation on page 227 is excerpted from Beck, EXTREME PROGRAMMING EXPLAINED: EMBRACING CHANGE, © 2000 by Kent Beck. Reproduced by permission of Pearson Education, Inc. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales (800) 382-3419 [email protected] For sales outside the United States please contact: International Sales [email protected] Visit us on the Web: informit.com/aw Library of Congress Cataloging-in-Publication Data Sterling, Chris, 1973– Managing software debt : building for inevitable change / Chris Sterling ; with contributions from Brent Barton. p. cm. Includes bibliographical references and index. ISBN-13: 978-0-321-55413-0 (hardcover : alk. paper) ISBN-10: 0-321-55413-2 (hardcover : alk. paper) 1. Computer software—Quality control. 2. Agile software development. 3. Software reengineering. I. Barton, Brent. II. Title. QA76.76.Q35S75 2011 005.1'4—dc22 2010037879 Copyright © 2011 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited repro- duction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc. Rights and Contracts Department 501 Boylston Street, Suite 900 Boston, MA 02116 Fax: (617) 671-3447 ISBN-13: 978-0-321-55413-0 ISBN-10: 0-321-55413-2 Text printed in the United States on recycled paper at Courier in Westford, Massachusetts. First printing, December 2010 Thank you to my children, Ashon, Diya, and Aman, who put up with their daddy writing so much, and especially thank you to my beautiful wife, Shivani, who enabled me to write this book. This page intentionally left blank C ONTENTS Foreword xv Introduction xxi Acknowledgments xxxi About the Author xxxiii Chapter 1 Managing Software Debt 1 Where Does Software Debt Come From? 1 Software Debt Creeps In 3 Software Asset Depreciation 5 Like-to-Like Migration 6 Limited Expertise Available 8 Expensive Release Stabilization Phases 8 Increased Cost of Regression Testing 11 Business Expectations Do Not Lessen as Software Ages 12 Summary 14 Chapter 2 Technical Debt 15 Origins of Terminology 16 Other Viewpoints on Technical Debt 16 Definition of Technical Debt 18 Patterns of Technical Debt 19 Schedule Pressure 19 Duplication 20 Get It “Right” the First Time 21 Acknowledging Technical Debt 22 Pay Off Technical Debt Immediately 23 Strategically Placed Runtime Exceptions 25 Add Technical Debt to the Product Backlog 28 Summary 30 ix