Preface

Philippe: I ran into technical debt long before I had a name for it. In 1980, I was working at Alcatel on some peripheral device, and the code had to fit in 8 kilobytes (kB) of ROM (Read-Only Memory). With the deadline to “burn” the ROMs approaching, we did a lot of damage to the code to make it fit, thinking, “Oh, for the next release we’ll have 16 kB available, we’ll make it right”… We did get 16 kB of ROM for the next release, but we never, ever fixed all the abominable things we had to do to the source code because the deadline for the next product was, again, too close. New programmers coming on board would say, “Wow, this is ugly, brain-damaged, awful. How did you end up writing such bad code?” Colleagues would reply, “Oh, yes, go ask Philippe, he’ll explain why it’s like that. At least, on the bright side, it does the job and passes all the tests. So, fix that code at your own risk.”

Robert: With the advent of agile practice, I was interested in hearing stories from developers about how it scales. Two projects in different organizations at the time were adopting agile and had recognized the importance of an end-to-end performance requirement. The demos for the minimal viable product were an unquestionable success. It just so happened that in each case, the demo sparked a new high-volume bandwidth requirement. One project was able to take the new requirement in stride while the other project “hit the wall,” as Philippe would say. The architecture and supporting processes were not sufficiently flexible to allow the project to quickly adapt. This got me thinking about the choices that developers make to produce more features or to invest in architecture and infrastructure.

Ipek: I believe software engineering is first an economic activity. While in principle budget, schedule, and other business concerns should drive your design choices, that has not been my experience in many of the systems I worked on. A package routing system, let us call it the GIS-X, is a canonical example. I was part of the team that conducted an architectural evaluation of the system in 2007. The development team was tasked to incorporate advanced geographic information processing to GIS-X to optimize driving routes. As the schedule realities started to take priority, each of the five development teams working on the project started diverging from the design. Among several other technical issues, one key mistake the organization made was not assigning an architecture owner to keep the design, business, and resource constraints in check.

Around 2005–2008 the concept of technical debt started to emerge, in the form of myriads of blog entries, mostly in the agile process community. We realized that developers understood technical debt very well, even when they were not calling it that, but the business side of their organizations had little insight and saw it as very similar to defects. The three of us met several times around that time, and we initially worked on developing a little game about hard choices to help software teams get a better feeling for what technical debt is about. As we found more people both in industry and academia willing to understand more about this strange concept that did not fit very well in any software engineering narrative, we started in 2010 organizing a series of workshops on Managing Technical Debt, initially sponsored by the Software Engineering Institute (SEI), to explore more thoroughly the concept. We’ve had one workshop a year since. They have grown in importance and are now a series of annual TechDebt conferences.

The three of us wrote papers together and made presentations—short ones, long ones—to diverse audiences all around the world. Our varied views started to converge in 2015, and this is when we thought of writing a book about technical debt. It proved to be still a bit of a moving target.

We interacted with many people over the past eight years or so, and the book you have in hand is the result of these collaborations with hundreds of people. With their help, we made great strides in understanding the phenomenon behind the simple metaphor of technical debt. We think we now better understand where technical debt comes from, what consequences it has on software-intensive development projects, and what form this technical debt actually takes. We now say with certainty that all systems have technical debt, and managing technical debt is a key software engineering practice to master for any software endeavor to succeed. We’ve heard how different organizations cope with it. We looked at and tried tools promising to perform miracles with technical debt. We also understood the limits of the simple financial metaphor: We realize now that technical debt is not quite like your house mortgage.

This book is intended for the many practitioners who’ve heard the term and those who think that it may have some relevance in their context. Hopefully it will give you tools to analyze your own situation and put names on events and artifacts you are confronted with.

This is not a scientific treatise, full of data and statistics. There are other venues for this. But we will give you concrete examples that you can relate to. It is also illustrated with stories that some of our friends from our industry have contributed, telling you their experience of technical debt in their own words.

Philippe: I now see that my 1980s story about 8 kB of ROM is a very clear-cut case of technical debt, triggered by pure schedule pressure, with severe consequences on the maintainability of this small piece of code. I attended the 1992 OOPSLA conference in Vancouver where Ward Cunningham used the term “technical debt” for the first time. At last I had a name for it.

Robert: Reflecting on the two projects adopting agile, I first approached the problem thinking that architecture infrastructure needed to be equally visible as features in the product backlog. That gave me some, but not all, the tools I needed to understand the choice in selecting one or the other. I now see that adding technical debt items to the backlog brings visibility to the long-term consequences of the choices as they are made together with more needed tools to strategically plan and monitor those choices as technical debt.

Ipek: A few months ago in one of the software architecture courses I teach at the Software Engineering Institute (SEI), an attendee approached me to ask if I had ever worked on the GIS-X system. He happened to be one of the engineering managers on the team. He recalled our recommendations and in reflection reassured me that while at the time we did not phrase our findings using the words, we were spot on that the technical debt they had resulted in the project being canceled. A full circle moment.

It does not stop here. Now you will have to share with us and the community your stories about technical debt. This book is not the end”…only a start.

Philippe Kruchten, Vancouver
Robert Nord, Pittsburgh
Ipek Ozkaya, Pittsburgh