If this were a book...

Hello again. Sorry it’s taken me a while to write this edition of the newsletter — I’ve been busy getting to the MVP stage with my new website kevinrutherford.info, which will have an emphasis on mob programming training, my software development coaching work, and of course this newsletter.

Anyway, back to the newsletter. Thus far I’ve been writing articles to get them out of my system and off my ancient to-do list — or occasionally somewhat at random, as the topics occurred to me. So part of the delay in producing this article has been because I felt I needed to start planning a bit more. Are these posts building towards something other than just a random set of musings? Is there an identifiable story arc or structure? Do I have a purpose in doing this?

And so I’ve been wondering this week: what if this series of articles were to grow into a book? Would that be a desirable outcome for you, dear reader? And if so, what might that book look like?

I guess many — perhaps all — of the articles so far could maybe form a decent basis for an imaginary introductory section, but then what? What direction should I take?

So without any commitment to actually following through on the idea, I envisaged a Contents Page that looks something like this:

---

1. Part I — INTRODUCTION

   1. Why do we need another book about refactoring?

   2. What is code quality anyway?

      • Why is Habitability important?

      • The 4 Rules of Simple Design

      • What do I mean by Implicit vs Explicit Coupling?

2. Part II — PRACTICAL ADVICE

   1. WHEN — Deciding when to refactor

      • What does Refactor Mercilessly mean in practice?

      • When should we refactor?

      • RED, GREEN, REFACTOR or RED, REFACTOR, GREEN?

      • When have we done “enough”?

   2. WHAT — Deciding what needs to be refactored

      • How can we detect Implicit Coupling?

        • The role of Connascence

        • Coupling that involves our tests

        • Coupling that doesn’t involve programming language code

      • When does coupling A have higher priority than coupling B?

   3. HOW — Deciding how to refactor

      1. The Role of Domain Language in Refactoring

      2. How can we make Implicit Coupling explicit?
         [I envisage this to be the meat of the book, consisting of patterns / recipes / worked examples for dealing with various forms of implicit coupling, and examining the role of different programming languages and other technologies in finding good solutions.]

---

Does that seem reasonable? Do you think anything is missing? Would you read this book? Please let me know in the comments — and who knows where this will lead us!