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.