Personally, one of the most fascinating things that is currently taking place in the software industry is the speed and frequency at which companies like Google, Amazon, Netflix etc. ship their code to production.

These companies are long past the age where a production deployment was a major milestone, and required a whirlwind of activity by many different teams to accomplish.

However, the majority of other companies are still a few years behind these players, and production releases are still a big deal, and are a quarterly event at best.

I have always been curious about how companies such as Google manage testing because in almost every project that I have worked on testing has been this huge monolithic activity that has given everyone headaches. And given how much time testing takes I couldn’t imagine how someone ships their code multiple times a day to production?!

How Google Test Software is a very insightful book into the leading practices and philosophy behind Google’s testing. It is written by people who have been deeply involved in testing for Google, and I’ll paste a little snippet about the authors here to give you a sense of their background and expertise on this subject.

James Whittaker is an engineering director at Google and has been responsible for testing Chrome, maps, and Google web apps. He used to work for Microsoft and was a professor before that. James is one of the best-known names in testing the world over.

Jason Arbon is a test engineer at Google and has been responsible for testing Google Desktop, Chrome, and Chrome OS. He also served as development lead for an array of open-source test tools and personalization experiments. He worked at Microsoft prior to joining Google.

Jeff Carollo is a software engineer in test at Google and has been responsible for testing Google Voice, Toolbar, Chrome, and Chrome OS. He has consulted with dozens of internal Google development teams helping them improve initial code quality. He converted to a software engineer in 2010 and leads development of Google+ APIs. He also worked at Microsoft prior to joining Google.”

The biggest takeaway for me from this book was the focus on automating tests, and on treating testers and developers the same way. The idea that a tester and a developer should have the same skills because the tester will ultimately write code to automate tests was new to me, and one that made a lot of sense if you think about test automation as one of the key things that will enable consistent quality and speed to market for your product.

Another wow moment for me was reading that in Google people raise bugs in the automated tests, and treat automated tests just as they would treat the code itself!

I also really liked the last chapter on the role of test engineers and test managers in the future, and how the authors see this shaping up. It is a little bit of a dire forecast if you are in this role yourself, but I do the see the industry tending in the direction of wanting fewer specialist testers and therefore test managers, and instead the mindset is shifting towards quality being the responsibility of every developer, and quality being baked into the development process itself.

Overall, I quite liked the book; I would however say that there seems to be a lot of repetition in the book, and it could have been a lot shorter without losing any of its key messages.  That being said, there’s a lot to learn from this book, and was a definite worthwhile read for me.

I finished reading The Tattooist of Auschwitz today, and absolutely loved it. I’ve visited Auschwitz and Birkenau a few years ago, and until I read this book — it was impossible for me to imagine that any sort of love could exist there.

This book is historical fiction about Lale who is a tattooist that etches numbers on everyone who comes to Auschwitz, and Gita who is a prisoner there, and is about their love.

What’s incredible about the book is that it is a magnificently uplifting story, and most of it is true. I’ve read some criticism of the book that talks about some of the finer details not matching historical accuracy, but I think the critics are missing the point with the book on this one.

That such love, kindness, friendship and hope could exist in the place where perhaps the worst atrocities in the history of humanity were inflicted is for me the point of this story.

This is a great story, and I am sure that I will read it again – and I can also whole heartedly recommend it to everyone.

Related reading: NYT Review of the Book.

I recently finished reading Jeff Sutherland’s – Scrum: The Art of Doing Twice the Work in Half the Time, and thoroughly enjoyed it and can recommend it to anyone interested in Agile and Scrum. I have been doing Agile and Scrum since 2011, so I like to think that I have a fair bit of experience in the ceremonies, and practical aspects of Agile, but the book was a great read on the history of how Agile came into being, and the philosophy behind these ceremonies, and a deeper look at the why not the how of Agile and Scrum.

I have already written a post on how why Scrum is called Scrum based on what I learned from this book, and there were several other things like this that I learned from the book such as Jeff Sutherland’s efforts to modernize the FBI’s database, and his experience with Japanese car manufacturers, and how that led to the role of the Product Owner being created in Scrum.

The philosophy and history behind each of the Agile ceremonies, principles, roles, and the problems that these were solving were the biggest takeaway for me from this book.

Also, at a high level, I think it is very useful to hear from Jeff Sutherland as to why Agile is so much faster than traditional waterfall development, and understand how it is the agility of teams that leads to faster development, not an individual coding 4x faster.

Personally, I feel that 4x productivity is probably not true for most teams, and while it is a good goal to aspire to I don’t think that a lot of projects were really done in 25% of the cost in a very conventional sense. I feel that Agile eliminates waste in terms of building something that no one wants, and to that extent maybe that 4x productivity number is correct, but this is really my only gripe with the book.

All in all, I think this is a very good read, and also a very easy read that you can finish in a couple of sittings, and one which everyone who’s dabbling in Agile or Scrum should invest time in.