Home > Articles

  • Print
  • + Share This
This chapter is from the book

Who Is This Book For?

There are many books and tools that can help you understand how to analyze your software. And there are yet other books that can help you adopt new technology for building microservices, migration to the cloud, front-end web development, and real-time system development. There are also many good books that walk through different aspects of software development, such as software code quality, software design patterns, software architecture, continuous integration, DevOps, and so on. The list is long. But there exists little practical guidance on demystifying how to recognize technical debt, how to communicate it, and how to proactively manage it in a software development organization. This book fills that gap.

We address the roles involved in managing technical debt in a software development organization, from developers and testers to technical leads, architects, user experience (UX) designers, and business analysts. We also address the relationship of technical debt to the management of organizations and the business leaders.

People close to the code should understand how technical debt manifests itself, what form it takes in the code, and the tools and techniques they can use to identify, inventory, and manage technical debt. This is the inside-out perspective.

People facing the customers—the business side of the organization, such as product definition, sales, support, and the C-level executives—should understand how schedule pressure and changes of direction (product “pivot”) drive the accumulation of technical debt. They should be especially conscious of how much the organization should “invest” in technical debt, without repayment, and for how long. This is the outside-in perspective.

Both sides of the software development organization—technical and code-facing or business and customer-facing—should understand the reasoning and decision processes that lead to incurring technical debt and how the consequences of debt result in reduced capacity. They should also understand the decision processes involved in paying back technical debt and getting development back on track. These decisions are not merely technical. For sure, technical debt is embedded in the code base and a few connected artifacts. But its roots and its consequences are at the business level. All involved should understand that managing technical debt requires the business and technical sides of the organization to work together.

  • + Share This
  • 🔖 Save To Your Account