Talent Is Overrated is one of those books that you wouldn’t know about unless you are bored in an airport and wandering the bookstore. But wander I did and am glad for it. Talent is Overrated is basically another take on the whole notion of Deliberate Practice which gained some publicity in Outliers and the whole ’10 000 hours’ thing. Colvin doesn’t use that figure but offers 10 years instead. But rather than just touching on it for a chapter or two, what we have here is a full book.

The first three chapters are the setup by illustrating the fallacy of the existence of prodigies and how they all, whether intentionally or not, did deliberate practice on their field of excellence for at least ten years before achieving their peaks.

Chapter five is here things get interesting with the elements of deliberate practice.

• Designed specifically to improve performance
• Can be repeated a lot
• Feedback on results is immediately available
• Highly demanding
• Isn’t much fun

These characteristics are discussed a bit in an article in Fortune by the author (which is also an editor there). Different people have different takes on these characteristics, naturally. This one lists eight for instance. (That site also links to How Entrepreneurs Acquire the Capacity to Excel: Insights from Research on Expert Performance which is a less-mass-market paper on the subject.)

Chapters six and seven discuss techniques for actually doing deliberate practice including some models for it. I think the model that works for testing is the sports model. This model’s learning is broken into two categories; general conditioning and specific training. In sports, conditioning is things like cardio and stamina but in testing it is more systems thinking and application and domain knowledge. Specific training is interesting because the application of the training will always be different. Just as no two pitches or golf lies are the same not two testing contexts are exactly the same.

Since this is primarily a business book, you can likely skip the how-to-apply-it-to-the-office unless you are the one making culture decisions at which point it is imperative to read. The last chapter is about passion (a truly extraordinary drive) and its motivation and had some good things for structuring both intrinsic and extrinsic motivators.

I have no idea how to apply the concepts of deliberate practice to testing. I suspect things like Weekend Testers come close, but don’t really cut it as they are only once a week. Testing Dojos don’t either also due to their infrequency. The Miagi-Do School of Software Testing sounds like it might also come close but I can find nothing to link to that really describes it. (Matt — fix that would you?)

Off the top of my head, I would guess that only James and Michael really do what could be considered deliberate practice by constantly proposing new games, puzzles and challenges to each other. But that arrangement works (I suspect) largely on their work with RST and might not for others.

Anyways, back to the book review. Should you care about deliberate practice? Absolutely. Should you buy the book? For me, I don’t regret the $20-ish I spent on it but if you just want the deliberate practice nudge and none of the background / proofs then you can likely skip it. Instead, go do some practice.

In what could have been the the most important keynote at a Quality Conference this year, Kent Beck delivered his Software G Forces talk at STP Con last month. To me, the most impactful idea of the year is Continuous Delivery and this talk is about not just the technical problems you encounter, but the organizational and business ones that companies have to tackle in order to do it. I’ve since suggested to more than a few people that they should print out the deck, tape it on the wall and use it as a checklist.

A lot of my notes were taken straight from the slides so are wonderfully redundant since the deck is embeddable. But there are a couple things that I don’t think are there.

• Inspiration is preparation plus panic
• The trick is to identify the visionary crazy people from the crazy crazy people
• Automated acceptance tests – when you have 3 months to deploy you don’t have 2 months to test
• Subscriptions – when you release all the time, customers don’t want/expect to be billed each release and it also decouples the billing cycle from the development one
• Getting rid of the QA department does not mean getting rid of the testers — just the organizational split
• Even with complete automation as a goal, things that need human judgement still require humans
• Rollbacks are triggered by business metrics not technical metrics
• If death is the alternative, then radical change is appropriate. Otherwise, test the water