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.

I recently finished reading this book, and I think it is a great resource for any improving chess player. The big idea of the book is that you need to develop a sense for when tactics are present in the game, and there is a specific method to do that. The book lists out certain signals that alert you to the presence of a combination.

An excerpt from the book explaining the signal:

A signal is a weakness in the opponent’s position. When we look for a signal, we look for a reason why we should be winning. Since Steinitz, we know that the combination does not appear randomly, but as a consequence of the positional superiority of one side. This superiority lies in positive factors, let’s say more active pieces. But we can take the opposite approach: looking at the opponent’s position, we can establish that he has passive pieces; or they may be trapped, locked in or lacking coordination.

Further, the book also lists out the signals you should look for in your game.

1. King’s Position
2. Unprotected Pieces
3. Alignment
4. Knight Fork Distance
5. Trapped pieces
6. Overloaded defender
7. Defence too far away

When you see a signal above appearing on the board – you should start looking for tactics, and combinations, and reading the book and practicing the puzzles in there help you do just that.

I was able to read, and implement these ideas immediately, and also without much conscious effort. When you practice the tactics based around a certain signal and theme then your brain starts looking for these patterns subconsciously and you will be able to find them in real time in your games.

This is an example from a recent game I played:

Black has just played Qd7 and castling would be quite normal for white here. However, I can sense that black played Qd7 to possibly castle queen side, and as soon as he does that his king and queen will be aligned on the light squares. I have a light square bishop which I can use, but it will unprotected at h3 which is the square from where I can attack him, and he also has e6 in reserve. Fortunately for me Nf4, solves both of those problems, and you can see this is exactly how the game goes.

This book was very useful for me, and I recommend it wholeheartedly to anyone looking to improve their chess tactical ability.

I have read this book twice now, and I find it immensely helpful. This book can be read in a few hours, and while it probably doesn’t contain anything you didn’t already know – it is always helpful to be reminded of such things specially when you are going through a stressful period in your own life. This is also touched upon in the book itself which has the following passage:

There are several quotes in the book which I quite like, and this is consistent with Dale Carnegie’s writing as well, which lends it a familiarity when you are reading it.

An example of a quote I really liked: