Customer Reviews, including Product Star Ratings help customers to learn more about the product and decide whether it is the right product for them.
To calculate the overall star rating and percentage breakdown by star, we don’t use a simple average. Instead, our system considers things like how recent a review is and if the reviewer bought the item on Amazon. It also analyzed reviews to verify trustworthiness.
Reviewed in the United States 🇺🇸 on September 4, 2017
This book has many great stories about software problems that are irritating us repeatedly or driving us mad, and that are costing our society a lot of money. Which is something that we should be more aware of.
The stories make you think about things that at first look simple, but in practice aren't. Like the story on post code that differ in length, where some countries don't have them, and not all of them are numeric; in the Netherlands we actually have four digits and two characters. Think about that when you design a input form and ask the user to enter the post code and validate it before giving the error message "Post code should be five digits".
The book also provides ideas that will help you prevent problems and make software more human friendly. Thank you Gojko!
Today, much of our lives depend on software. However, people, in average, are actually not that good at building software and a lot of things can go wrong. With this book, Gojko points out that they have gone wrong, over and over again. Mistakes in software has caused a lot of pain, suffering, money and sometimes lives.
In Humans vs Computers, Gojko Adzic shares a collection of stories about software gone wrong. Of systems behaving the wrong way, crashing, turning off, sending tickets to the wrong place, making wrong transactions, declaring people dead who are still alive, and other horrible things. This was often because the developers of the system didn't imagine the particular use of the system. They didn't understand the customer and the customer domain well enough. To them it probably seemed like a trivial thing but the impacts on people's life can be huge.
The books is structures around stories. Stories of similar themes are grouped together which also creates a bit of a flow between the stories. The book ends with simple tips for developers to avoid these kind of mistakes.
I thoroughly enjoyed reading about the stories. Some of them were just funny and others were shocking. All of them were written really well. For just the book about the stories, I'd rate it as 4 stars. But the ending with the summary on how to prevent this changed the book from a story book to one that probably every developer ought to read. 5 stars and recommended reading!
Reviewed in the United States 🇺🇸 on December 17, 2017
I’ve never laughed so much while learning so much. Gojko Adzic’s book is both essential reading and a pleasure.
Let me explain why I think this book is so important. The IT community has been learning that it must build all of its systems “ruggedly” (in the sense promoted by the Rugged Software movement) – that is, build in a way that is secure, scalable, resilient, available, flexible, and that fails gracefully, when it must fail. None of these qualities can be added after the fact, but must be built in from the beginning. As the principle has it, "I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended." It is difficult for us all to learn how to do this. Adzic’s book shows us the kinds of things we must think about in order to build ruggedly, especially when we have a global user base and Internet scale. Through entertaining stories and examples, Adzic is teaching us how we must now think when we develop systems.
I am also always on the lookout for IT books that that can be read profitably by the non-IT community. I think this is one of the rare books that gives a non-IT audience some sense of the complexities faced in building software, and some insight into why and how systems fail. I would recommend this book for everyone in IT – and everyone who ever uses, touches, or relies on any software system!
Reviewed in the United States 🇺🇸 on October 20, 2018
With Humans vs Computers, you will discover the importance of software quality through the consequences of its absence. All developers without exception are subject to the kind of bugs presented in this surprising book. The author did an impressive work to collect the vast collection of true stories, most having make the front page of newspapers. There are not the kind of bugs you could easily catch with a solid suite of automated tests - cultural differences, hidden biais, poor process automation, or the subtleties of commonalities (time, postal address, name) - with always the same result, we are disconcerted by the (often disastrous) consequences.
I really like this book, so much I couldn't put it down. It's one of the few books I felt disappointed when I turned the last page. The idea of this book is excellent. The stories are funny, captivating, each more surprising than the last. I would like every developer reads this book, but as it's not technical at all (contains no code), every software users will be delighted, astonished, bewildered, entertained by it.
The book ends with a few guidelines to avoid problems presented in other parts. I found this part helpful but anecdotal, given that seeing the consequences has, in my opinion, a far biggest impact toward less error prone software.
Reviewed in the United States 🇺🇸 on January 2, 2018
Gojko has done a great job of collecting stories to help us remember how important it is to test beyond the happy path. We often rely on computer’s doing the “right thing”, but it is easy to miss the edge conditions or forget to think about consequences of what we code.
I’ve been heard to say … once or twice … that one of the most important things testers can do is ask questions… those pesky ‘what if’ questions. Many of the stories he has shared could have been prevented by asking basic questions and looking at different scenarios. Towards the back of the book, there is a nice summary of different test ideas based on the examples – some that I hadn’t considered and have since used to help my own testing.
Basic things we should consider like personal names, addresses, time, numbers, and process automation. For example, so many different variations for personal names to think about. I think my favorite, is to remember that people’s real name might be a fictional character such as Superman. It's not one I had considered in my last testing effort - that people may have a single name so we need to remember to figure out how to deal with that, and how it might feed into other systems.
Overall, the book is entertaining and I had some good chuckles, but in my opinion, the real gold of the book is the ideas to consider before coding.
Reviewed in the United States 🇺🇸 on October 11, 2017
I did two 5 hour train trips and the book proved awesome reading. I did the whole thing in two gulps!
Needless to say, I love the book. It's a great idea and the author tell the stories with such a wonderful tone and humor. The last chapter adds a nice touch of usefulness to the book as I get some very practical (and now funny) tips on how to avoid the problems described and make a more trustworthy, reliable and stable system.
This is a book full of stories seasoned developers love to tell each other in the after-the-talks-pub. Keep one close and you'll be the center of attention at any good conference bar.
I'm reading each page with a gentle smile on my lips, bursting out in laughter every few pages. What a bizarre world of exceptions we live in. What a mess we create trying to shoehorn that exceptional world into conformist models of the computer.
In the "February 2038" chapter I could not control myself anymore; I created an event called Boom on 1/2 2038. A lot of strangeness happens with the calendar input control on an iPhone after that ... Fun to be able to break systems in real time!
Reviewed in the United States 🇺🇸 on October 12, 2017
You might wonder how problems arise with computers (aka software). This book explains how, clearly and with a sense of humor. From parking tickets/fines to invalid input to my favorite, the reboot to fix a timing/memory leak problem. We program and test our systems. But, do we check for conditions that can cause failure, or worse, cascading defects?
Gojko wrote a terrific book that explains how things got that way. Even better, he has an entire chapter on what we could do about it: The Inverse Monkey Rule. If you are not sure of how you might mistake-proof your code, or create better tests, read that chapter. Yes, both developers and testers should read that chapter. If you're a manager or project manager, and you want your team to skimp on testing, read the rest of the book. Then, read that chapter. The additional testing won't take much longer and will prevent the kind of sad/funny defects Gojko explains in the rest of the book.
Read this, and sigh (if you're like me) or weep. Then, get to work.
Reviewed in the United States 🇺🇸 on September 15, 2017
As I was enjoying this book, I realized that in my long career in software development I had seen a previous writer who wanted to sound a wake-up call to the challenges of writing and delivering working code. It was Robert Glass https://smile.amazon.com/Robert-L.-Glass/e/B000AQ4HWQ/ref=sr_tc_2_0?qid=1505480154&sr=1-2-ent -- still writing at 85! Both authors have a laundry list of funny, irreverent, timely, and horrifying dilemmas caused by the software we foist on an unsuspecting public. As Gojko notes, the real problem now is that the software is assumed to be right. That means, dear readers, that you must pay the court costs and suffer the humiliation, injury, and even death, without hope that anyone will notice or care unless you take action to defend yourself. It's sad to think that we have come to this sorry state. There is a small bright side in this fun-to-read-in-a-way book, the final chapter on steps to take to increase awareness of the errors the book described. I think this chapter should be included in academic courses and displayed on the walls of development organizations. Thank you, Gojko!
Reviewed in the United States 🇺🇸 on November 10, 2017
As with the author's other books, this is another gem.
I work in IT Operations and I'm often the first guy to get shouted at by the business when bad things happen with software. Anything we can think about up front to avoid a catastrophe in production has got to be a good thing, right?
Some of the stories written about here look familiar, but there were plenty I’ve never considered. This book gives rich food for thought for anyone involved in building or maintaining software – or indeed anyone that finds technology interesting and just wants a good read.
This book makes you think: How would that scenario affect me? Am I exposed anywhere to something similar? One thing I did figure out is that I hit retirement age in January 2038, so I should be able to dodge anything that goes tits-up when 32-bit integer dates blow up the following month. Something to look forward to in old age ;-)