Tag: book reviews

I grabbed this book over the 2024 holiday season as it was on sale and recommended by the DevOps practitioners over at ITRevolution.

A Radical Enterprise looks at a new way of building organizations, actually a few way, where the power and decisions are decentralized.

I am pretty open to trying new things and experimenting, but I was very skeptical this would work in many places as I started this book and remain so after finishing it. I kept thinking this felt like a feel-good, kumbaya approach to running an organization. Giving responsibility, devolving it from management to individual teams and having them collaborate together and with other teams.

While I am skeptical, there are some large organizations doing this, and the description says 8% of corporations do this, which I find hard to believe. In any case, a few of them are:

• Haier – USD$38b in revenue
• Morning Star – processing about 40% of the world’s tomato products
• Buurtzorg: – over €427 million revenue
• Nearsoft – $80mm consultancy
• W. L. Gore & Associates – makers of Gore-Tex products, over US$3b in revenue

Those are some impressive organizations. Maybe 8% isn’t wrong, but it feels high. I’ve worked in a few organizations, and all of them have a more central control organization. Even at Redgate, where I think we give a lot of autonomy to teams, I wouldn’t think we’re in the category of a radical organization.

There are some principles to this idea, and some imperatives. The imperatives are:

• Team autonomy – giving control to small groups in terms of how they practice and schedule work as well as allocate themselves.
• Managerial devolution – trying to allow individuals or teams to manage themselves
• Deficiency Gratification – gratifying our higher level needs. Not things we need, but we want and desire. I’m not sure I completely understand this.
• Candid vulnerability – being open and transparent. Even for someone like me that is fairly open, this is asking a lot.

Ultimately, I’ve worked with too many people who aren’t motivated, who don’t try and drive forward, who don’t want to make decisions, or who don’t want accountability. I think many of the people I’ve worked with wouldn’t thrive in this type of org and would get booted. Maybe that’s OK, and maybe this is only suited to some types of people.

It’s an interesting idea, and I found myself fascinated and rooting for success, but always thinking this wouldn’t work in most places I’ve worked. Maybe all the places I’ve worked.

Give it a try if you want a different way of thinking about work, and if it’s for you, maybe look for a job at one of these organizations.

I’m out today, coaching in Salt Lake City. However, I’ve been thinking about a few books after discussions with various customers and attendees at a few events. I wanted to give you a few recommendations on books that I think are good reads for thinking about DevOps.

The Mythical Man Month

I can’t remember if I read The Mythical Man Month in college or early in my career, but it’s a seminal book in our industry. It talks about a lot of problems with building software in large projects.

I’ve re-read this a few times, most recently during the pandemic. However, it’s a good once-a-year book to remind yourself of why we try to become better engineers.

If you’ve never read it, you should pick up a copy and give it a go.

The Goal

I read this before The Phoenix Project, and had a sense of deja vu with the Phoenix Project as these are very similar stories. I think The Goal is the better book, and worth a read. I hadn’t read it in a few years, but I restarted it recently because it helped me re-think about how I might approach some of the challenges my customers face.

The book is set in an analog world, with manufacturing equipment in a factory, but if you think about the machines as your dev systems and the different operators as developers, you start to see how and why bottlenecks occur.

The Phoenix Project

A rewrite of The Goal in many ways, The Phoenix Project is the software dev side of the IT world, showcasing, or maybe exaggerating the issues we face. It’s short, easy to read, and funny in places.

Or maybe sad.

I found myself remembering similar situations as I read it. I think I’ve read this every year or two to remind myself of how silly we can be.

Worth picking up for you or your team, especially if you struggle with building software efficiently that meets your clients’ needs.

The DevOps Handbook

I’ve read a few books that were geared to the more technical side of DevOps or software. There are even more recent books, like Accelerate, tackling the topic, but I liked the DevOps Handbook one best. It breaks down the different stages we struggle with in software, and provides some sort of maturity model to help you think about how to better build software.

I really enjoyed this book, though it was long. It took my quite some time to get through, but it was worth the time as I had to stop and think about how I might tackle some of these situations.

There are more focused, and more modern articles/blogs/etc, on the various topics in here, but this is a great general overview of modern software development.

I was approached by Manning Publications and asked to review 100 SQL Server Mistakes and How to Avoid Them. They gave me a free copy of the book (and offered a second one as well), but didn’t put any conditions on my work.

This is a preliminary review of the EAP version of the book, which is still in progress as of now. If you buy the book, you can get digital chapters as they are written and edited, as well as the final book.

This is part of a series of book reviews I’ve done on my blog. You can see them all under the book reviews tag.

100 SQL Server Mistakes

The book is designed to give you 100 things that people commonly do wrong with a SQL Server instance and/or database, and starts with mistake 0 being that people think

From there, the book goes into an explanation of the 4Cs diagrams, which are ways of representing systems. This was mildly interesting to me, though less useful when I was reading on my mobile as seeing the details of the diagrams is hard.

The first few mistakes are on standards. Naming, prefixes, using sp_, and more. I liked this as I think that having some good basics communicate information between team members, or even users of your database for reporting. There are reasons given for why each of these is a mistake, as well as example code to showcase potential issues.

Data Types are the next set of mistakes, showing common things people do when designing their data model or objects. There is also a few mistakes on database design with common mistakes that people make.

There are sections for T-SQL mistakes, including error handling as well SSIS mistakes and installation problems. Each of these is grouped together with a variety of common issues that people may run into.

The version I have of the EAP is 8 chapters, with a few more to come. Overall, this is less a what you should do, and more of a what you shouldn’t do. I like this approach. Aaron Bertrand did something similar with his Worst Practices series. Often we are stuck with certain designs, and we may not be able to implement best practices. However, we should try to avoid worst practices.

I’d even say that if you have some worst practices, don’t continue them for the sake of continuity or consistency. Start refactoring or at least improving new development.

This book is a good reference for beginner to intermediate SQL Server developers and administrators, and might even be a good gift for welcoming employees early in their SQL Server journey. Many of these would be guidelines I’d want to implement for  a team.

If you’re looking for some knowledge to help you avoid producing bad code, check out this book. It doesn’t have all the answers, but it has some good thoughts on code smells and ways to correct them. It might give you inspiration to fix some code in your shop.

If you want another view, Kevin Feasel has his own thoughts.

You can pick up the book here: https://www.manning.com/books/100-sql-server-mistakes-and-how-to-avoid-them

This is very off topic, but I’ve been a fan of Rush since I was about 12 years old. Their Moving Pictures

This is a few thoughts on Geddy Lee’s memoir, My Effin’ Life.

This is part of a series of book reviews I’ve done on my blog. You can see them all under the book reviews tag.

Geddy is Jewish

I might have known this, but I hadn’t really thought about it. The book opens with his thoughts on his parents, who were Holocaust survivors. The chapter of the book looks at his life as a child, memories of parents and sports growing, without a lot of music. The second talks religion and then the book goes into his parents’ journey and meeting in Poland, getting separated into concentration camps and being reunited.

It’s a tough read for me, as I don’t love the WWII era, but it’s also amazing that they met and were reunited. There is some love there. This story must have affected Geddy, and he talks of going back to visit as an older man, taking his Mother with him.

Early Rush

I don’t think I knew how close Geddy and Alex were. They were friends in school, growing up and enjoying the music of the 60s. I didn’t realize how much of an influence some of the early bands (Cream, Yes, Eric Clapton) were for them. I also didn’t realize the forming, breaking, reforming that took place with a different drummer. I certainly didn’t know that the first Rush album was John Rutsey, who quit for various  reasons.

The audition for Neil Peart is short, but it’s a fun story.

A Long Marriage

Like Bono, Geddy met his wife in school, and it’s been amazing they are together still.  They haven’t had, it appears, as smooth a marriage as Bono, partially from all the travel and distance that Geddy had with the band. He freely admits this, and also talks throughout the book about working on his marriage and getting counseling. An interesting admission.

It also makes me realize I’d have been a poor rock star because I like being at home and spending time with my wife.

The Journeys

It’s interesting to hear about these three musicians growing and changing, being influenced, and partying hard. I saw some interviews at some point and thought these guys didn’t party as much as they were sports fans.

Wrong. They partied a lot, and the book talks about their fondness for drugs, though not with the destruction and wildness (usually) of the Eagles, Motley Crue, Ozzy, etc.  They also found themselves influenced by Neil, who loved to read science fiction and fantasy, which influenced their music.

They toured with Kiss and Led Zeppelin, things I hadn’t realized. I think most of my discovery of Rush was after Permanent Waves.

It’s interesting to read how much they are on the road, and at the same time, how few places they went. They were mostly a US/Canada touring band, getting to Europe some, but not many other places. Neil didn’t like Japan, and is the shy one.

I found the book interesting from a fan’s point of view, and I put some of the albums on as I read different parts of the book. I’d forgotten some music, and honestly, didn’t love the albums after Signals (as a 20-ish yr old) and stopped listening to them, but I’ve gone back and found I do enjoy some of the music, though the late 70s-80s remain my favorite era of the band.

If you’re a fan, you might enjoy this book, learning a bit about the artists and their journey.