I got into a rhythm of publishing a chapter a week without really paying attention to the outline. I’d just pick the next unfinished chapter I felt ready to write and write it. (Sometimes I wasn’t ready, as you’ve seen, but that’s part of the process.)
Here’s the thing—we’re down to 6 chapters undrafted:
Coupling
Infection (mechanisms of coupling)
Data?
Coupling Versus Decoupling
Cohesion
Beneficially Relating Elements
I’m both excited & a little deflated. Excited because the end is in sight. The book won’t be done just because all the drafts are finished. I’m struggling with the order of the theory chapters. It’s one of those tangled-yarn situations where everything seems to rely on everything else. I may have to slice & dice a bit to create a flow.
The deflation is because there are so many important (to me, anyway) topics I won’t have covered. I knew this would happen when I split of this chunk of “software design as geek self-care” from the rest of software design. I knew it but I didn’t really internalize it. I’ll come to the end of this book with so much more to write about. More to write about than when I started, actually.
As a reminder, the next book will be about software design within the team, “software design is an exercise in human relationships” where the humans involved have similar incentives & perspectives to the reader. I’m starting to get excited about this topic, getting glimpses of what I’m going to talk about.
What I wanted to say to you all (4700 subscribers, 400 paid, thank you!) is that what you’d like me to talk about is more important than what I want to talk about. Comment here or DM me. Where are you struggling with software design? Where are you frustrated that your software design skills seem to fall short? What interpersonal situations seem most fraught for you as a software designer? The more you ask, the more I can answer (& the more I learn).
Thank you again for your time & attention, your interaction, stories, thoughts, & thank you for telling your friends.
Congrats on getting close to complete! I'll be interested to see what you might be able to come up with on the possible "Data" chapter. Lately I've been thinking a lot about the Stack Overflow survey https://stackoverflow.blog/2022/03/17/new-data-what-makes-developers-happy-at-work/ that called out "Lack of productivity" as the #1 factor that predicted developers being unhappy at work. I definitely feel this myself when I have a week where I'm not getting as much done as I hope, but I wouldn't have predicted that type of unhappiness would outweigh "work/life balance" and the rest. It seems like a possibly interesting applications of data could be to help affirm when a productive week is happening, even if it's just in the backend or API, where there is little visual manifestation of progress.
Many of the chapters you've completed so far feel like they create a recipe for a faster-moving team, but if it's not possible to measure how much improvement might be possible by following the methods, then the utility to our team would be lower. Easier said than done to compare velocity of a repo w/ and w/o tidying, but to the extent it is possible it makes the suggestions more persuasive.
As the next book will be about the team, and if my memory serves the third would be about the organisation at large, I'm thinking flow. Like inedibill mentioned in a previous comment one of the main frustrations for many is lack of productivity. I've found that this is mostly caused by a lack of flow. Tidying is a way to increase flow of change, just as TDD is. But scaling this to the team and to the organisation is a different ballgame altogether. XP is certainly a way to go. I'm sort of thinking it would be nice to get more of that sort of stuff. What works, what doesn't, how to introduce, I don't know. Somewhere there. In some form. With or without references to XP as such. In the same conversational style you usually use (that I absolutely love by the way :) ).