My perspective is as a mid-thirties adult male who went straight from college to a job I'm still at 11+ years later, working on a large, sprawling, legacy software suite with almost no unit test coverage. Our software is the culmination of 40+ devs and contractors who came and went over the product's 20+ year lifespan. There was never an architect. There was never much oversight, pretty much pick whatever stack you wanted to build a certain feature as long as the resulting UI was vaguely consistent. Half of our application is served by legacy Java and half is ASP .NET, and most of the time navigating the software you can't tell from the UI which codebases served your page (or what parts of your page). It is hundreds of thousands of lines of tangled legacy code which all sorts of different database access strategies and UI frameworks depending on who wanted to experiment with what at the time they were there making a new feature.
Having not known anything other than this one project for my entire career, and not having a college or professional work culture that ever pushed testing on us (until now), it was kind of eerie to read through this book and find seemingly endless examples of the issues and challenges that obstruct my normal work every single day. I feel like I understand better now why some people are adamant about testing, it would have made a huge difference in what it's like to work on this legacy project of ours today, if it had been a priority way back when.
It is also evident to me however after reading the book that testing is not like some magic bullet, either, and just sprinkling some tests around doesn't fix problems like the ones I face. The author comes off a bit over-excited about how unit tests could change your life (paraphrasing), and he is right, but you have to put in the actual work. I would describe it like getting hooked by one of those old Bowflex TV commercials and so you get the workout equipment and then realize "wow, I am going to have to do a lot of work to get the results I want", and then this book is at least trying to be your workout guide on what muscle groups you should be exercising and roughly how to do it. Pretty useful but you still have to put it all together yourself into a routine that is right for you/your team/your project, and then actually do the work, continuously. Reading this book and then not applying the advice within will get you about the same results as reading a book about workouts and exercise for a healthy body and then continuing to not exercise and eating fast food for lunch every day.
I think in my case after working in real-life examples of whats in this book for over a decade very little of it surprised me in any way, but it was helpful to see these things spelled out with their cause and effect, ideas for solutions, how to at least avoid making the problem worse, etc.
I understand now why some people we would hire as new developers to the project would get all sad and disappointed when they asked about tests and we told them we really don't have any. I literally never knew any better and wasn't convinced until I read this book.
So I would say that all devs/engineers should read this book at least once, there is value in it for sure. On the downside, prepare yourself for a difficult and dull slog. The book, for all its wisdom within, is not particularly engaging to read and the examples are just. plain. awful. Truthfully even if I had read this book 10+ years ago when I was getting started, I'm not sure the examples would have spoke to me (because they are terrible), which might have made it less convincing. But it was the case that at the time I read this I had been working and playing with live examples for a decade-plus as I said before so all the examples he described were perfectly apparent to me in my own project's code. His examples stink.
I think it would help newer developers if there was a digital copy that you could provide some parameters and get examples in only a language that is familiar to you. That and also re-write all the examples to not stink somehow. I don't know, the examples are hyper-realistic in the sense that "yeah, I have definitely seen people write garbage like this all the time," but the things he is trying to demonstrate in these examples don't have to be made more realistic by using awful naming, spacing, lack of comments, etc. Just my personal opinion.
It is a difficult book to force yourself to keep reading through, in my opinion, but you definitely should and you will most likely be glad you did.
Loading your book clubs
There was a problem loading your book clubs. Please try again.
Not in a club? Learn more
Join or create book clubs
Choose books together
Track your books
Bring your club to Amazon Book Clubs, start a new book club and invite your friends to join, or find a club that’s right for you for free.
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required. Learn more
Read instantly on your browser with Kindle for Web.
Using your mobile phone camera - scan the code below and download the Kindle app.
Flip to back Flip to front
Follow the Author
Something went wrong. Please try your request again later.
 |
Frequently bought together
- +
- +
Total price:
To see our price, add these items to your cart.
Choose items to buy together.
More items to explore
Page 1 of 1 Start overPage 1 of 1
From the Publisher
Must-Read for Every Programmer and Developer
This classic, endorsed by Robert "Uncle Bob" Martin (author of Clean Code), is on many must-read lists for programmers and developers including lists featured on Guru99, DZone, Built In, Dev Community (dev.to), and more.
"The book is important, as almost every developer at some point in career, has to work with a legacy system and it still represents the most challenging problems for many companies. The book goes deep into understanding the general process of a software change like adding features, fixing bugs, optimizing performances, etc."
—Milan Milanovic, DZone, November 2021
About the author
Follow authors to get new release updates, plus improved recommendations.
The book is good so far, but don't get it here. Apparently this is an "Abridged" version, but I wouldn't even call it that. I've compared this physical copy with a PDF version and parts of sentences and sections are missing in a way that doesn't even make sense. Sentences at the bottom of a page are cut off without an ending, and an entirely new section starts on the next page. On one two page spread (shown in photos), a chart is duplicated, pushing the content down, and the rest of the content that is supposed to be on that page is just omitted entirely. The attached photos are of three pages from my physical copy with the issues I described, and the same three pages from a free PDF version of the book.
Images in this review
Top reviews from other countries
Skiamakhos
Everyone who works as a maintenance developer should read this.
Reviewed in the United Kingdom 🇬🇧 on May 14, 2014
Mongol
A decent book for 2004 but hopelessly outdated in 2019
Reviewed in the United Kingdom 🇬🇧 on July 4, 2019Frank R.
A good summary of techniques you might have used
Reviewed in the United Kingdom 🇬🇧 on May 17, 2014ALASTAIR TAYLOR
Code sample formatting on Kindle edition
Reviewed in the United Kingdom 🇬🇧 on September 25, 2013dina
Every engineer should have a copy
Reviewed in the United Kingdom 🇬🇧 on August 20, 2019
