TF? Book Outline

For now...

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:

1. 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…

2. 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.

3. 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.

4. 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.