Tidy First A Personal Exercise in Empirical Software Design (Kent Beck) (Z-Library)

Tidy First? A Personal Exercise in Empirical Software Design Kent Beck Foreword by Larry Constantine

SOF T WARE DEVELOPMENT “Design is about the shapes we paint with our code, and Kent helps us to paint better shapes. This is an important book on an important topic.” —Dave Farley Founder and Director of Continuous Delivery Ltd. “This book gives excellent practical tips to help any developer improve the code they work with.” —Sam Newman Independent consultant, technologist, and author of Building Microservices and Monolith to Microservices “The ideas in Tidy First? are simple, and yet, you will wonder why you haven’t thought about many of these before. Recommended for anyone who cares about clean and readable code.” —Gergely Orosz The Pragmatic Engineer Tidy First? Twitter: @oreillymedia linkedin.com/company/oreilly-media youtube.com/oreillymedia Messy code is a nuisance. “Tidying” code, to make it more readable, requires breaking it up into manageable sections. In this practical guide, author Kent Beck, creator of Extreme Programming and pioneer of software patterns, suggests when and where you might apply tidyings to improve your code while keeping the overall structure of the system in mind. Instead of trying to master tidying all at once, this book lets you try out a few examples that make sense for your problem. If you have a big function containing many lines of code, you’ll learn how to logically divide it into smaller chunks. Along the way, you’ll learn the theory behind software design: coupling, cohesion, discounted cash flows, and optionality. This book helps you: • Understand the basic theory of how software design works and the forces that act on it • Explore the difference between changes to a system’s behavior and changes to its structure • Improve your programming experience by sometimes tidying first and sometimes tidying after • Learn how to make large changes in small, safe steps • Approach software design as an exercise in human relationships Kent Beck, creator of Extreme Programming, is a pioneer of software patterns, coauthor of JUnit, rediscoverer of Test-Driven Development, and observer of 3X: Explore/Expand/ Extract. Alphabetically, he’s the first signatory of the Agile Manifesto. Kent lives in San Francisco, California, and he is Chief Scientist at Mechanical Orchard, teaching skills to help geeks feel safe in the world. US $39.99 CAN $49.99 ISBN: 978-1-098-15124-9

Praise for Tidy First? Kent Beck is always worth listening to, and I have been waiting for the advice in this book for several decades now. This book helps to move the focus in software away from the tools and technology, and firmly onto what really matters, design! Design is about the shapes we paint with our code, and Kent helps us to paint better shapes. This is an important book on an important topic. —Dave Farley, Founder and Director of Continuous Delivery Ltd. With code bases that are hard to understand, it can be difficult for a developer to know where to start. This book gives practical tips for a developer at any level to help improve the code they work with. —Sam Newman, independent consultant, technologist, and author of Building Microservices and Monolith to Microservices Kent Beck shares dozens of easy-to-follow ideas on how to turn complicated code into a simpler form. The ideas are simple, and yet, as you read them, you will wonder why you haven’t thought about many of these before. Recommended for anyone who cares about clean and readable code. —Gergely Orosz, The Pragmatic Engineer For decades, refactoring books have focused on top-down, object-oriented software design theories. Tidy First? breaks the mold by providing a realistic approach to incrementally improving real production code. —Maude Lemaire, author of Refactoring at Scale

Let’s be honest: 99% of a software engineer’s job involves working on brownfield projects. This can be difficult, especially if the code wasn’t written with readability in mind. In this book, Kent Beck turns things around by prioritizing human relationships through code. He succinctly teaches how to improve software design with small, gradual changes, thereby making the code clearer for both you and your colleagues. —Vlad Khononov, author of Learning Domain-Driven Design

Kent Beck Foreword by Larry Constantine Tidy First? A Personal Exercise in Empirical Software Design Boston Farnham Sebastopol TokyoBeijing

978-1-098-15124-9 [LSI] Tidy First? by Kent Beck Copyright © 2024 Kent Beck. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editors: Melissa Duffield, Louise Corrigan Development Editor: Michele Cronin Production Editor: Christopher Faucher Copyeditor: Rachel Head Proofreader: Piper Editorial Consulting, LLC Indexer: nSight, Inc. Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Kate Dullea October 2023: First Edition Revision History for the First Edition 2023-10-17: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781098151249 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Tidy First?, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

To the blessed memory of Professor Barry Dwolatzky: geek extraordinaire, elemental force, and inspiration.

Table of Contents Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Part I. Tidyings 1. Guard Clauses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Dead Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Normalize Symmetries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. New Interface, Old Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Reading Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Cohesion Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Move Declaration and Initialization Together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Explaining Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Explaining Constants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Explicit Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 vii

11. Chunk Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. Extract Helper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 13. One Pile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 14. Explaining Comments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 15. Delete Redundant Comments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Part II. Managing 16. Separate Tidying. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 17. Chaining. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 18. Batch Sizes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 19. Rhythm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 20. Getting Untangled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 21. First, After, Later, Never. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Part III. Theory 22. Beneficially Relating Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 23. Structure and Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 24. Economics: Time Value and Optionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 25. A Dollar Today > A Dollar Tomorrow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 26. Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 27. Options Versus Cash Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 28. Reversible Structure Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 viii | Table of Contents

29. Coupling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 30. Constantine’s Equivalence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 31. Coupling Versus Decoupling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 32. Cohesion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 33. Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Appendix: Annotated Reading List and References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Table of Contents | ix

Foreword This slim volume, the first of a series, is for professional programmers–that breed of software developers with a deep and geeky interest in their craft and in improving their work in small ways with big payoffs. The author, Kent Beck, is just such a dedi‐ cated professional, ever attentive to detail and ever in tune with the larger issues and the bigger picture. Practicing software developers often pay scant attention to theory, but Kent knows what he is talking about when he mixes practice and theory into a guide to tidy code that is both readable and practical. In theory, there is no difference between theory and practice, while in practice there is. Various versions of this pithy pronouncement have been widely and incorrectly attributed to Albert Einstein and Yogi Berra, among others. Only a nerdy wordsmith (guilty as charged!) would care that the correct attribution is to Benjamin Brewster, a student at Yale writing in an 1882 edition of the Yale Literary Magazine. Thanks to the dedicated word geeks at QuoteInvestigator.com, I can offer this bit of geeky detail confident of the audience here: this is a profession that hinges on getting the details right. In bringing theory and practice together, Kent starts at the bottom, with tiny snippets of code and meticulous attention to small details, then works his way up to the larger view that explains the process of creating cleaner code that is more robust in the face of inevitable changes and corrections. In assembling this guide to practice, Kent ulti‐ mately draws on the real-world economics of software development along with core theory in software engineering. That core theory is simply this: that the complexity of computer code depends on how it is organized into parts, on how coupled those parts are with each other and on how cohesive the parts are in themselves. The source of the theory of coupling and cohesion is usually attributed to my book with Ed Yourdon, Structured Design (Your‐ don Press, 1975; Prentice Hall, 1979), although it can be traced all the way back to a 1968 conference presentation in Cambridge, Massachusetts. Coupling and cohesion xi

almost didn’t make it into the 1979 Prentice Hall edition. The editors tried to con‐ vince Ed and I to omit the two chapters because “no one is interested in theory.” For‐ tunately for the history of software engineering, the authors prevailed and the editors were proved wrong. The theory has since been validated through a half century of practice and literally hundreds of research studies and investigations. Coupling and cohesion are simply measures of the complexity of computer code, not from the perspective of the computers executing the programs but that of human beings trying to understand the code. To understand any program, whether to create it or to correct it or to change it, requires understanding the piece of code immedi‐ ately in front of you as well as those other pieces to which it is connected, which it depends on or affects or is affected by. It is easier to understand the immediate piece of code if it all hangs together, if it makes sense as a whole, if it forms what cognitive psychologists call a gestalt. That’s cohesion. It is also easier to understand it in terms of its relationships with other pieces of code if these relationships are few and rela‐ tively weak or highly constrained. That’s coupling. Coupling and cohesion are really all about how your brain deals with complicated systems. See? Nice and tidy. That’s the theory. Now on to the practical details and the mix with just enough theory to make sense of it all. Kent Beck will ably guide you on the way. — Larry Constantine Rowley, Massachusetts 9 October 2023 xii | Foreword Larry Constantine is a former professor at the University of Madeira, Portugal, and the University of Technol‐ ogy, Sydney, Australia. He has more than 200 papers and three dozen books to his credit, including the Jolt Award winner, Software for Use (Addison Wesley, 1999), written with Lucy Lockwood, and fifteen novels under his pen name, Lior Samson.

Preface What Is Tidy First? “I have to change this code, but it’s messy. What should I do first?” “Maybe I should tidy the code before I make the change. Maybe. Some. Or maybe not?” These are questions you might ask yourself, and if there were easy answers, I wouldn’t have felt the need to write a book to address them. Tidy First? describes: • When to tidy messy code before changing what it computes • How to tidy messy code safely and efficiently • How to stop tidying messy code • Why tidying works Software design is an exercise in human relationships. In Tidy First? we start with the proverbial person in the mirror—with the programmer’s relationship with themself. Why don’t we take time to care for ourselves? Take time to make our work easier? Why do we go down the rabbit hole of cleaning code to the exclusion of work that would help our users? Tidy First? is the next step in my mission to help geeks feel safe in the world. It’s also the first step to take when faced with messy code. Software design is a powerful tool to ease pain in the world— if it is used well. Used badly, it becomes just another instrument of oppression, and a drag on the effectiveness of software development. Tidy First? is the first of a series of books focusing on software design. I want to make software design approachable and valued, so I’m starting with the kind of software design you can do on your own. Subsequent volumes will apply software design to heal relationships between the programmers on a team, and then address the biggie: xiii

the relationship between business and technology. But first, let’s understand and practice software design in ways that benefit our daily work. Let’s say you have a big function containing many lines of code. Before changing it, you read that code to understand what is going on. In the process, you see how you can logically divide the code into smaller chunks. When you extract those chunks, you’re tidying. Other kinds of tidying include using guard clauses, explaining com‐ ments, and helper functions. As a book, Tidy First? practices what it proposes—delivering these tidyings in small chunks and suggesting when and where you might apply them. So, instead of trying to master tidying all at once, you can try out a few tidyings that make sense for your problem. Tidy First? also begins describing the theory behind software design: cou‐ pling, cohesion, discounted cash flows, and optionality. Audience This book is meant for programmers, lead developers, hands-on software architects, and technical managers. It is not tied to any programming language, and all develop‐ ers will be able to read and apply the concepts in this book to their own projects. This book assumes that the reader is not new to programming in general. What You Will Learn By the end of this book, you will understand: • The fundamental difference between changes to the behavior of a system and changes to its structure • The enabling magic of alternating investment in structure and investment in behavior, as a lone programmer changing code • The basics of the theory of how software design works and the forces that act on it And you will be able to: • Improve your own experience of programming by sometimes tidying first (and sometimes tidying after). • Begin to make large changes in small, safe steps. • Prepare to design as a human activity with diverging incentives. xiv | Preface

Structure of the Book Tidy First? is divided into an Introduction and three parts: Introduction I begin with a brief description of my motivations for writing this book, how I came to write it, who it’s intended for, and what you can expect. Then we dive right in. Part I, “Tidyings” A tidying is like a little baby miniature refactoring. Each short chapter is a tidy‐ ing. If you see code like this, then change it to code like that. Then send it to production. Part II, “Managing” Next we cover managing the tidying process. Part of the tidying philosophy is that it should never be a big deal. It’s never something that has to be reported, tracked, planned, and scheduled. You need to change this code, and it’s hard to change because it’s messy, so you tidy first. Even as part of daily business, this is still a process that improves with thought. Part III, “Theory” Here’s where I finally get to spread my wings and dig deep into the topics that excite me. What do I mean by “software design is an exercise in human relation‐ ships”? Who are these humans? How are their needs better met with better soft‐ ware design? Why does software cost so damn much? What can we do about it (spoiler alert: software design)? Coupling? Cohesion? Power laws? My goal is for readers to begin reading in the morning and be designing better that afternoon. Then designing a little better every day after that. Pretty soon software design will no longer be the weakest link in the chain of delivering value with software. Why “Empirical” Software Design? The loud debates in software design seem to be about what to design: • How big should services be? • How big should repositories be? • Events versus explicit service invocation. • Objects versus functions versus imperative code. Preface | xv

These what debates hide a more fundamental disagreement among software design‐ ers: when? Here’s a caricature of the poles of this disagreement: Speculative design We know what we want to do next, so let’s design for it today. It will be cheaper to design now. Besides, once the software is in production we will never have the chance to design, so let’s pile it all in today. Reactive design Features are all anyone cares about, so let’s design as little as we can today so we can get back to features. Only when features become nearly impossible to add will we begrudgingly improve the design, and then only just enough to get back to features. I aspire to answer the question of “when?” with “somewhere in the middle.” When we observe that a certain class of features is hard to add, we design until the pressure is relieved. We start with just enough design to get the feedback cycles going: Features What do users want? Design How can programmers best be supported to deliver those features? The empirical software design answer to the question of when is contingent. Design some time around when you can take advantage of the design. Answering this ques‐ tion requires taste, negotiation, and judgment. Is requiring taste and judgment a weakness? Sure, but it’s an inevitable weakness. Speculative and reactive design also require judgment, but they give software designers fewer tools to work with. I like the word empirical to describe this style because it seems to clarify the distinc‐ tion I’m making with speculative and reactive design timings. “Based on, concerned with, or verifiable by observation or experience rather than theory or pure logic.” Sounds about right. How I Came to Write Tidy First? As an undergraduate I took a course on software design that used the book Structured Design by Ed Yourdon (RIP) and Larry Constantine. I didn’t understand much of the book, mostly because I hadn’t yet encountered the problems it addressed. Fast-forward 25 years to 2005. I had designed a bunch of software by this time. I felt like I had a pretty good grasp on design. Stephen Fraser organized a panel at OOP‐ SLA (the big object-oriented programming conference) to celebrate the 30th anniver‐ sary of the publication of the book. Ed and Larry were to be on the panel, along with Rebecca Wirfs-Brock, Grady Booch, Steve McConnell, and Brian Henderson-Sellers. xvi | Preface

If I didn’t want to get blown off the stage, I had some homework to do. So I cracked open my yellowing copy of Structured Design and started reading. Hours later I looked up, absolutely enthralled. Here were Newton’s laws of motion, but for software design. It was all so clear when it came out. How did we as an industry forget that clarity? I remember the panel going well. A highlight of the conference was breakfast with Ed and Larry, two extremely bright guys completely comfortable with themselves and each other. Figure P-1 shows the signatures they left in my textbook long ago. Figure P-1. Inscriptions by Ed Yourdon (“Don’t believe anything you read in this book!”) and Larry Constantine (“…including the above!”) The book was showing its age by that time. Examples using paper tape and magnetic tape were no longer relevant. Nor was the discussion of assembly language versus the new higher-level languages. The basics, though, were spot on. I vowed that I would bring that material to today’s audience. I made several abortive attempts to write a software design book in the intervening years (search for “Kent Beck Responsive Design” if you want to see what I was up to). It wasn’t until 2019 that I unexpectedly had two weeks of completely unscheduled time. I decided to see how much of the book I could write in those two weeks. Ten thousand words later, I had learned an important lesson— I wasn’t going to be able to tackle all of software design in one book. One scenario that kept coming up in what I had drafted was this moment of small-scale design: I have some messy code— do I change it or do I tidy it first? Preface | xvii

My book-writing experience has always been like this. Take a topic that seems too small for a book. Write. Discover the topic is way too large for a book. Take a tiny, too-small slice. Write. Discover the slice is too large. Repeat. And so here you hold (virtually or for real) the first fruits of that now nearly 20-year- old vow. I found that in discussing that hourly question, “Should I tidy first?” I have been able to touch on many of the topics dear to my designer heart. I look forward to your feedback and to continuing to deepen my understanding of all that makes soft‐ ware design fun and valuable. O’Reilly Online Learning For more than 40 years, O’Reilly Media has provided technol‐ ogy and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-889-8969 (in the United States or Canada) 707-829-7019 (international or local) 707-829-0104 (fax) support@oreilly.com https://www.oreilly.com/about/contact.html We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/tidy-first. Email bookquestions@oreilly.com to comment or ask technical questions about this book. For news and information about our books and courses, visit https://oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly-media xviii | Preface