Book review: The Patient Assassin

On 13 March 1940, Udham Singh shot and killed Michael O’Dwyer, the former lieutenant governor of the Punjab in India. This was done in revenge of the 1919 Jallianwala Bagh massacre.

Anita Anand’s The Patient Assassin, A True Tale of Massacre, Revenge and the Raj from 2019 tells the tale of what happened during the 1919 Jallianwala Bagh massacre, and how it led to Udham Singh’s life mission of taking revenge on the men responsible for the massacre.

Anita Anand not only covers the massacre and the assassination, but also explains the environment that allowed the massacre to happen in the first place, gives us a glimpse into the thoughts and feelings of the men responsible, while walking the tightrope of not dismissing their monstrous actions, but at the same time allowing us to understand how they could have acted the way they did. The majority of the book, however, is dedicated to Udham Singh and his life, both before the massacre, and after the massacre, tracing his movement across the globe, until that fateful day in 1940. It also covers the trial after the assassination.

The book paints a nuanced and as detailed a picture of Udham Singh as is possible. Udham Singh was in many ways a deeply flawed man, who did a lot of harm to a lot of people on his way to his revenge. This is covered, as is his work towards an independent India, and even his interactions with local Indian populations in England and the US. It gives us a glimpse into the man, and not just the assassin that the English saw, nor just the martyr-hero, honored in his home country after his death, and especially after their independence.

I highly recommend this book, as an introduction to how the British Raj treated the Indians, and how the Indian independence movement became a geo-political tool for the different countries (including Nazi Germany and the Soviet Union) in their political maneuvering, as well as a historical account of both the 1919 Jallianwala Bagh massacre and the life of Udham Singh. It also gives a glimpse into how Indians were treated in England and the US in the twenties and thirties.

I first became aware of the book through the HistoryExtra podcasts episode about the book.

 

 

Book review: Range by David Epstein

Around Christmas, I read Range: How Generalists Triumph in a Specialized World by David Epstein, which is a book which really speaks to me, since I have had a somewhat uneven path to my current career. Something which I think is a strength – which Epstein’s book definitely backs me up on.

The first part of the book, takes on both the idea of focused children becoming child prodigies and the 10,000 hour rule, which says that it takes 10,000 hours of intense training to become a world expert on something. Regarding child prodigies, Epstein points out that training children to become focused on one area, and thus become child prodigies in those areas only works on areas with well defined problem areas, e.g. chess, golf and to some degree classical music, while in areas which are more chaotic (most other sports, and other things interacting with other people), it doesn’t work. This is because the later areas are so-called wicked problems. Here a broadness of experience and range is a plus.

This means that world leaders in areas which can be considered wicked problems, usually haven’t just focused on those areas. Rather they have touched a number of different areas, before starting to focus on that particular area. One example Epstein mentions is that most Olympic competitors have usually dabbled in a number of sports before choosing their discipline.

From speaking of world experts in different areas, and their path to become so, Epstein broadens the subject to discuss career paths in general. He takes on the idea that people should choose their path from a young age, and that changing career paths later in life is somehow bad. He, rightfully, points out that the earlier you make your choices, the less options are you aware of – heck, the less options might exist.

This rings true to me. The job I do now, working as a business analyst in software projects, didn’t really exist when I had to choose my path after high school. I instead started studying business management and later switched to economics, before becoming aware that computer programming was something I found interesting. Now, I have again moved away from doing actual programming, and instead work with the business, ensuring that the end system will be useful. One of the reasons I am effective at this job, is my technical background, but it is certainly also helped by my early years studying business management and economics.

One other factor Epsteins mentions, when it comes to choosing a career path early, is the fact that peoples’ brains keep developing, and that you are different person when you are older than when you were younger. This should make you pause – think of all the decisions you made back then, which you have since changed as you have lived more years, experienced more things – why should your career path be any different?

If you change career path in your later life, you have both the advantage of having a wider range of experience to base the decision on, and you will still have your toolbox from your old career to use in the new career. This means that you might be able to solve problems which other people in the field can’t, since they simply lack the required tools.

Much the same can be said about focusing on diversity in teams. It has been shown again and again that the more diverse a team, the better they are at problem solving. Again, because they bring a more diverse set of tools to solve the problems, and not just the same tools that they have all learned in school.

I have simplified the arguments a bit, but I hope you get the general gist. Epstein also provides a lot of concrete examples of cases where range and diversity has helped over narrow expertise.

All in all, I highly recommend the book, and I hope the message of the book is taken to heart.

Book review: Accelerate

Book review of Accelerate: The Science Behind DevOps – Building and Scaling High Performing Technology Organizations by Nicole Forsgren, PhD, Jez Humble, and Gene Kim.

If you have been at any programming or agile related conference within the last 8 months or so, you will probably have heard people recommend Accelerate. One of the reasons it is often recommended is that it explains the importance of DevOps for high performing tech organizations. This is not really anything new, but what Accelerate does, is base it on actual science, and not just anecdotes and opinions – something we see all too often in the tech field.

The findings of Accelerate is based upon the survey data collected through the yearly survey “State of DevOps” in the years 2014-2017. Those data clearly demonstrated that a high performing organization performed much better than a low performing organization, but they could also be used to explain what caused this differences in performance.

The book is split into 3 parts, a conclusion, and some appendixes. The first part explains the findings, the second part, the science used, and the third part is a case study contributed by Steve Bell and Karen Whitley Bell. I will go through each part separately below.

The first part of the book is called “What we found”, and what they found is certainly noteworthy. They looked at some key indicators of software delivery performance, and found that a high performance organization had the following performance compared to low performance organizations:

  • 46 times more frequent deployments
  • 440 faster lead time from commit to deploy
  • 170 times faster mean time to recover from downtime
  • 5 times lower change failure rate

These numbers are from page 10 of the book, and show a much greater difference than most would expect, no matter how big a proponent of DevOps.

The rest of the first part of the book goes through their other findings, which identifies “24 key capabilities that drive improvement in software delivery performance, and, in turn, organizational performance”. According to the authors, “[t]hese capabilities are easy to define, measure, and improve”.

I won’t include the list here, but many of them relate to DevOps practices and lean management practices, though there are a couple related other things, such as architecture. One thing I will mention, is that the findings indicate that while culture has an influence on the use of DevOps techniques, the use of DevOps techniques also have an influence on culture, which changes as a result of that.

None of the mentioned capabilities are new, but here we have, for the first time, evidence that they actually work, and help improve performance.

The second part of the book, “The Research”, goes into how the research was conducted, and why survey data was suitable for the research. It doesn’t include the actual data, which would have been nice, but I can understand why that isn’t the case (breach of confidentiality etc).

I can’t recall seeing a similar chapter in any other book on programming/systems development, and I highly applaud it. I also think it was a smart move to put it in the second part, rather than the first part, as most people will be more interested in the findings, rather than the methods behind finding them.

The third part of the book, the case study contributed by Steve Bell and Karen Whitley Bell, is called “Transformation”. They takes us to Ing Netherlands, a world-wide bank, where they have been involved in a cultural change, started and lead by the IT manager, enabling the organization to become high-performance.

To be honest, I find this part to be the weakest part of the book, both in content and in presentation, but it does provide a nice overview of practices on the team, management, and leadership level (it can be found online here).

All in all, the findings of the book should not be shocking to people who has worked with agile, DevOps etc., but it is nice to have a list of proven capabilities to focus on. It is also a useful tool when debating with management about these subjects.

I highly recommend the book to people working in any aspect of software engineering – be it as a programmer, a project manager, in a leadership position, or in any other capacity.