Scan barcode
rodhilton's review against another edition
5.0
You're wasting time reading this review, you could be reading this book instead.
Release It! is one of the most important books I think programmers can read, easily as important as the oft-cited classics like The Pragmatic Programmer or the GoF book. Release It! isn't about writing super-spiffy code, or object-oriented design, but it should drastically affect how professional programmers write their code. It focuses on what engineers need to do to get their software into a state where it can actually be deployed safely in a production environment. It covers patterns and antipatterns to support (or subvert) stability as well as capacity, and the section of the book covering this is simply excellent. But then it goes beyond that to also discuss Operational enablement. Even if you're not into DevOps, and don't want to really be involved in DevOps work, this book gives you the tools and tips to do what aspect of DevOps is the purview of pure developers.
Nobody who writes production enterprise software should write another line of code until they read this book. I honestly can't give it enough of a glowing endorsement. Like any other patterns book, a great deal of it will be familiar to people who have been in the industry for a while, and have come up with (or encountered) its principles on their own. But I guarantee, if there's a single thing in the book you haven't seen before, it'll be worth reading the entire book, pretty much every section is gold.
My only complaint about it is that Michael Nygard has a tendency to go on randomish tangents, especially when talking about "case studies," which generally come off as the author trying too hard to convince the reader he knows what he's talking about. A lot of these stories are about things he personally encountered in his career, and how he fixed them, and each one has a weird arrogant quality, it's a little offputting to be honest, like Nygard is almost bragging. I get that these sections underscore the value of the ideas in the book, but there's something about how they're written that comes off boastful, or irritating in a way I can't quite put into words. What's more, the book STARTS with a particularly long one of these kinds of stories, making it kind of tough to get into the book. I actually tried to read it years ago and gave up on it very early. Only recently did I decide to revisit it and keep pushing forward (based on a co-worker's recommendation) and I'm extremely glad I did.
I highly, highly recommend picking up this book and reading it cover to cover. It's a struggle at first due to the unfortunate decision to start it off with one of the most annoying sections of the book, but I implore you to power through it and keep reading. It's worth it.
Release It! is one of the most important books I think programmers can read, easily as important as the oft-cited classics like The Pragmatic Programmer or the GoF book. Release It! isn't about writing super-spiffy code, or object-oriented design, but it should drastically affect how professional programmers write their code. It focuses on what engineers need to do to get their software into a state where it can actually be deployed safely in a production environment. It covers patterns and antipatterns to support (or subvert) stability as well as capacity, and the section of the book covering this is simply excellent. But then it goes beyond that to also discuss Operational enablement. Even if you're not into DevOps, and don't want to really be involved in DevOps work, this book gives you the tools and tips to do what aspect of DevOps is the purview of pure developers.
Nobody who writes production enterprise software should write another line of code until they read this book. I honestly can't give it enough of a glowing endorsement. Like any other patterns book, a great deal of it will be familiar to people who have been in the industry for a while, and have come up with (or encountered) its principles on their own. But I guarantee, if there's a single thing in the book you haven't seen before, it'll be worth reading the entire book, pretty much every section is gold.
My only complaint about it is that Michael Nygard has a tendency to go on randomish tangents, especially when talking about "case studies," which generally come off as the author trying too hard to convince the reader he knows what he's talking about. A lot of these stories are about things he personally encountered in his career, and how he fixed them, and each one has a weird arrogant quality, it's a little offputting to be honest, like Nygard is almost bragging. I get that these sections underscore the value of the ideas in the book, but there's something about how they're written that comes off boastful, or irritating in a way I can't quite put into words. What's more, the book STARTS with a particularly long one of these kinds of stories, making it kind of tough to get into the book. I actually tried to read it years ago and gave up on it very early. Only recently did I decide to revisit it and keep pushing forward (based on a co-worker's recommendation) and I'm extremely glad I did.
I highly, highly recommend picking up this book and reading it cover to cover. It's a struggle at first due to the unfortunate decision to start it off with one of the most annoying sections of the book, but I implore you to power through it and keep reading. It's worth it.
rodhilton's review against another edition
5.0
This remains one of the most important books software engineers can read. The second edition is even better than the first, updated to fix a lot of the "outdated" criticisms the first book gets, incorporating the modern DevOps movement, microservices, and modern technologies used in software engineering.
I really just can't say enough about this book. It's required reading. If you're responsible for code that runs on networked production systems, failing to read this book should be a fireable offense. Skipping "Release It!" is professional negligence. Stop what you're doing and read this before shipping another line of code.
Release It! is all about how to build cynical software, and once you start down that path you find that you can no longer think any other way. This book changes you and your career, it's just phenomenal. Even if you think you know everything in it because the patterns and practices it describes have become widespread, it's still worth reading.
The second edition fixes - or at least somewhat improves - every minor complaint I had about the first edition, and reorganizes the information, adds a lot of great new sections, and removes outdated cruft. It's superior to the first edition in every way, and that was a 5-star book for me.
I really just can't say enough about this book. It's required reading. If you're responsible for code that runs on networked production systems, failing to read this book should be a fireable offense. Skipping "Release It!" is professional negligence. Stop what you're doing and read this before shipping another line of code.
Release It! is all about how to build cynical software, and once you start down that path you find that you can no longer think any other way. This book changes you and your career, it's just phenomenal. Even if you think you know everything in it because the patterns and practices it describes have become widespread, it's still worth reading.
The second edition fixes - or at least somewhat improves - every minor complaint I had about the first edition, and reorganizes the information, adds a lot of great new sections, and removes outdated cruft. It's superior to the first edition in every way, and that was a 5-star book for me.
naleagdeco's review
5.0
This book is amazing.
If you are a person who is responsible for the operations, uptime, stability, responsibity of the system you write, or you are a developer who is being told you should care, this is the book for you.
It goes into understanding your system not just as the little piece of code you write but as a large thing with many moving parts that someone has to care about. It shows what to care about in the large ,but also how you can take that care and convert it into decisions and designs to make down at the individual component level.
All this time it's filled with lived experience, and the book is 100% designed for he practical, not the idealogical or theoretical.
Like probably many people, I became a devops person because I was the sucker who wasn't afraid of deploying the code on a unix server or who wasn't afraid to debug a working system in the late evening. As such I didn't have a formal or even learned ops background. This book is one of the things this year that I feel has actually qualified me to say I'm an ops person and not just a dev who plays one from time to time.
If you are a person who is responsible for the operations, uptime, stability, responsibity of the system you write, or you are a developer who is being told you should care, this is the book for you.
It goes into understanding your system not just as the little piece of code you write but as a large thing with many moving parts that someone has to care about. It shows what to care about in the large ,but also how you can take that care and convert it into decisions and designs to make down at the individual component level.
All this time it's filled with lived experience, and the book is 100% designed for he practical, not the idealogical or theoretical.
Like probably many people, I became a devops person because I was the sucker who wasn't afraid of deploying the code on a unix server or who wasn't afraid to debug a working system in the late evening. As such I didn't have a formal or even learned ops background. This book is one of the things this year that I feel has actually qualified me to say I'm an ops person and not just a dev who plays one from time to time.
adamchalmers's review against another edition
5.0
This is the book I wish I'd read before starting my career as a software engineer. University taught me how to write and debug code, but didn't teach me anything about managing programs in production or writing reliable distributed systems that can gracefully handle the chaos of a real-world network.
This book does a great job of explaining the problems you face running code in the real, high-scale world, walking you through war stories and asking how outages could have been prevented. Then explains a bunch of programming and architecture patterns you can use to avoid that. I really enjoyed it and highly recommend it for anyone who writes software where uptime matters.
This book does a great job of explaining the problems you face running code in the real, high-scale world, walking you through war stories and asking how outages could have been prevented. Then explains a bunch of programming and architecture patterns you can use to avoid that. I really enjoyed it and highly recommend it for anyone who writes software where uptime matters.
jiblits's review against another edition
3.0
The book is clearly dated though still has some good points/content. I suggest that if you read this you simply power through most of it and should get most of what you need from the section summaries.
The early parts of the book (Anti-Patterns and their counters such as Circuit Breaker) are definitely worth going over though.
The early parts of the book (Anti-Patterns and their counters such as Circuit Breaker) are definitely worth going over though.
miikka's review against another edition
3.0
It's a book about how to write software that works well in production, or perhaps operations-friendly software. It's important topic, but the book is already ten years old and precedes both the cloud and the devops movement, so it's somewhat outdated. It's not a bad book but I wouldn't recommend it today – I imagine there are more up-to-date books out there about the same topic.
readingroman's review
3.0
This book is a good reminder of the things that could go wrong when you ship software. It includes a few postmortems of real projects, which was helped crystallize "this could in theory happen to" into actionable steps you can take when you find yourself in that situation. There is something in each section that will make you question how well you really understand the stack your software lives on and motivate you to learn more...just in case.