I'm about halfway through the book (partial review here). I'm curious why you decided to organize it the way you did. The first part had very short chapters. Then part 2 had longer chapters so the flow was different.
Great question! We started out with 5 chapters. As we wrote, we realized we needed to break it up into even more chapters to make it more manageable. Over the year and a half of writing, we wrote over 600 pages, and cut over 300 pages of content.
We wanted to start out with explaining what DevOps is. Many folks have many definitions that end up detracting from creating a common dialogue. Each of the next 4 chapters are the pillars of devops, the essential foundations that make a difference in outcomes: Collaboration, Affinity, Tools, and Scaling. A lot of folks focus on the outcomes that arise from devops like continuous integration and continuous delivery.
The final part is the glue in how to connect the different aspects across different organizations in practice.
The structure evolved as we wrote it and it made sense at the time. It'd be great to get more feedback about the flow issues that you mention.
I finished the tools section today. I plan to finish the book Friday and then post my final review.
The "flow" issue I had was that the book started out fast moving and easy to read. The chapters were a couple pages to 15 pages. The concepts were simple ones that developers are likely to be familiar with. Or not a stretch.
Then I got to chapter 7. It was just under 40 pages. Which isn't excessively long for a chapter. But it is a big jump. In some ways it was still fast moving in that there were lots of section heads. It felt drier. Part of that is the material. I'm your stereotypical developer. I'm going to find soft skills topics less fun to read about. But there were less stories. In the tools chapter, we had the case studies at the end. (I'd have liked more stories to break things up, not just then end, but it gave me something to look forward to in the tools chapter.) By contrast the collaboration chapter did have a case study with Sparkle Corp but it was only a page long. And it wasn't labeled as a case study. So I wasn't looking forward to it and by the time I got there, I was tired of the topic.
The other difficulty I had with "flow" was something I shouldn't have been surprised about. O'Reilly "animal" books tend to be very information dense. When reading about code, I have no trouble with that information density. With the soft skills topics, I did. My brain couldn't focus on them for 40 minutes in a row. (I read computer books on my subway trip which is 40 minutes long.) So I was reading less per day because I couldn't read as long. By contrast, I read the entire tools section in one day today. I should have expected the information density, yet somehow it took me by surprise.
I don't dislike the book. I was just curious about this. (I think I"ll wind up with my initial guess of 7-8 horseshoes when I update my book review after finishing the book.)
Thank you so much for this valuable feedback! Really appreciate your thoroughness. We got some feedback that we had _too many_ stories at one point. So glad to get this feedback as it's something we fought hard to include as many as we did! I look forward to incorporating this feedback in Edition 2 (in which we hope to get more international stories included).