Author: Chris Sterling
Publisher: Addison Wesley, 2010
Pages: 288
ISBN: 978-0321554130
Aimed at: Agile programmers
Rating: 4
Pros: Extensive and detailed argument about software quality
Cons: Slow in defining its terms
Reviewed by: Andrew Johnson

This theoretical book looks at how agile software development can produce sustainable software and cope with change. Not an easy topic!

I have to admit I picked up this title without having come across the terms "software debt" or "technical debt" before. However, the reviews editor pointed out that this hardback book with an attractive photograph of tall redwood trees is part of the Agile Software Development Series so I agreed to take a look.

Next I was disoriented by the Foreword which, under the title, "Of Fairy Rings, Cathedrals, Software Architecture, and the Tallest Living Life Form on Earth" told me a great deal about Sequoia sepervivens - aka the coast redwood.  I turned back to the contents page to check I was reading the correct book.

The Introduction convinced me that the book was indeed about Agile software development methods, as did the appendix "What is Agile" which introduces Scrum and Extreme Programming. On the other hand Chapter 1: Managing Software Debt (same as the book's title) didn't help clarify the term "software debt"- though it did give me the clue that it was due to "bad code", isn't deliberate but creeps into software and then grows bigger. I still felt I would understand better if the terminology was defined.

Not long to wait - in Chapter 2: Technical Debt the first section is "Origins of Terminology" we learn that "technical debt" was coined by Ward Cunningham and that:

The term debt has become a common metaphor to describe how deferring quality in software leads to slower delivery of changes to that software in the future.

After this, and Chris Sterling's own definition of technical debt the book starts to make sense and we can proceed in the remainder of Chapter 2 to look at patterns of technical debt and strategies for coping with it.

Chapter 3: Sustaining Internal Quality rehearses the idea of a disciplined approach starting with a  familiar tenet of the agile method - sustainable pace - and continuing with others - close collaboration, small batches of work and refactoring. It mentions test-driven development and this is explained more in Chapter 4:Executable Design.

The next three chapters look at different areas susceptible to debt. Chapter 5 considers Quality Debt and argues for introducing automated testing early in the development cycle with ATDD (Acceptance Test-Driven development. Chapter 6 is on Configuration Management Debt including a discussion of documentation and Chapter 7 covers Design Debt and looks at robustness, modularity and changeability.

Chapter 8: Designing Software looks at reasons why application design decays as software ages, the benefits of incremental design and then moves on to consider the value of tools team for applying effective design in an iterative approach. 

In Chapter 9: Communicating Architectures Chris Sterling first presents three levels of architecture perspective - component, application and enterprise architecture and then explains that Architecture is S.A.I.D. - referring to structure, alignment, integrity and design. The chapter concludes with a look at modeling.

The topic of Chapter 10 is Technology Evaluation Styles and three are covered - research and spike are used when a team does not have enough skill to estimate a feature and tracer bullet which breaks down a large feature into parts that can be understood.

Finally we arrive at Chapter 11: Platform Experience Debt which looks at ways to share knowledge about all aspects of software with recommendations for pairing, training programs, personal development and collaborative team configuration and includes the conclusion that investing in people is probably the most effective way to create sustainable software.  

This book features lots of diagrams - the start of each chapter has a "conceptogram" (my term), a text diagram that outlines what is included in the chapter. Many ideas are illustrated with charts and graphs and these add a possibly spurious authority to the ideas being expressed. Given that Sterling never tells us where the data comes from for graphs that appear to assign monetary costs and benefits we can only assume the figures are plucked from the air and therefore meaningless. 

Footnotes and references, and the fact of being bound between hard covers, also add to the air of this being an important authoritative work. If you enjoy contemplating agile methodology you'll probably find a lot to think about as a result of reading it - and may even change your practices as a result.

On the other hand you might well think that this is just another collection of overworked jargon and a cute metaphor for something we all understand. Code deteriorates as you work on it due to the competing pressures of delivering working, feature-complete applications. Over time you might well hope to return to the low grade code and refactor it into something worthy but we all know that this is a tough thing to do when more features and bug fixes are pressing. Having a concept of debt, repayment and interest may be fun but does it add anything to your understanding or actions?