Foreword

In the late 1500s, a road was built encircling the island on which I now live. Well, not a road exactly, but more of a modest walking path, serving to connect the many small farming and fishing villages that flourished at that time. But, times change, and with the arrival of the whaling boats and the missionaries and the plantation owners in the 1800s, there was a clear economic incentive to reduce the friction of travel and to increase the capacity of transport. As such, using that original path as its architectural foundation, a wider road was built to accommodate horses and trains and the emerging motor car. Times changed yet again, and World War II necessitated yet wider and stronger roads, but—not surprisingly—corners were cut owing to the expediency of conflict. After the war, when the whalers, missionaries, plantation owners, and sailors were but an historical memory, that road remained, but now served to accommodate the cars of visitors who were arriving in alarmingly increasing numbers. Money for infrastructure being what it is, a new road was planned, but only partly built. The cost of maintaining the old parts of the road cut into the funds for building the new parts; but then, this is the nature of all systems. Even now, times change, and this time it is climate change, manifesting itself in the rise of the ocean and projected to reach three feet within the century. Already the ocean is encroaching on that ancient path and beginning to inundate the road in ways that make its replacement inevitable and urgent.

Software-intensive systems are a lot like that: Foundations are laid, corners are cut for any number of reasons that seem defensible at the time; but in the fullness of time, the relentless accretion of code over months, years, and even decades quickly turns every successful project into a legacy one. It is fascinating to watch young companies that grew quickly, unfettered by legacy code, suddenly wake up one day and realize that developing long-lived, quality software-intensive systems is hard.

What you have before you is an incredibly wise and useful book. Philippe, Ipek, Robert, and the other contributors have considerable real-world experience in delivering quality systems that matter, and their expertise shines through in these pages. Here you will learn what technical debt is, what is it not, how to manage it, and how to pay it down in responsible ways.

This is a book I wish I had when I was just beginning my career; but then, it couldn’t have been written until now. The authors present a myriad of case studies, born from years of their experience, and offer a multitude of actionable insights for how to apply it to your project. Read this book carefully. Read it again. There’s useful information on every page which, quite honestly, will change the way you approach technical debt in good and proper ways.

—Grady Booch
IBM Fellow
January 2019