I had a great session with @BethCodes last weekend that restarted the book writing. The big breakthrough was realizing that I had the book backwards. All the really juicy theoretical stuff, the stuff that gets me excited, well that stuff belongs at the back. đ˘
Instead, the more inviting approach is to get readers into the process Iâm describing as quickly as possible, then help them manage it, and then, if they really really want to, help them understand why it works.
That said, here is the current outline of Tidy First?: Daily Empirical Software Design:
Introduction. As little as possible introductory material about how I came to write the book, who itâs intended for, and what they can expect. Thatâs it. Absolute minimum. SighâŚ
Tidyings. A tidying is like a little baby miniature refactoring. Each is described as a promptâyou see code like thisâand a practiceâchange it to code like that. I currently have 13 tidyings outlined (you can see the beginning of the first one here). I expect to end up with like 20. The descriptions arenât longâsee code that looks like this, change it to code that looks like that, commitreviewpush.
Managing tidying. Next there is material about managing the tidying process. Part of tidying philosophy is that it should never be a big deal. Never something that has to be reported & tracked & planned & scheduled. You need to change this code, itâs hard to change because itâs messy, you tidy first. Even part of daily business, this is still a process that improves with thought.
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 relationshipsâ? Who are these humans? How are their needs better filled with better software 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.
The section on managing tidying reminds me of the practice of 3Sing (sweep, sort, standardize) in lean manufacturing. A daily, 30 minute session before core work begins can really transform a workplace (codebase). Looking forward to all this!
Hi Kent, thanks for the writing. I'm trying to better understand tidyings and I have a question. Some years ago I learned a lot by reading Martin Fowler's book about refactoring. I think I remember you participated in this book where there was a list of refactorings. It explained where to use them and which steps to do to safely execute on them. Do you think there's any kind of connection between tydyings and refactorings? Is tydyings a lower scale refactoring? Do they share a goal on structure but at different levels of abstraction (object vs method)?