Sunday, July 14, 2019

How 'aggregation of marginal gains' philosophy helps achieving compound gains in sports, and in software development ?

How do you go one to win 60% of cycling Gold medals on offer in Beijing Olympics in 2008 especially after having won just 1 Gold in last 110 years ?

This is exactly what England team did in 2008 Olympics. A story narrated in the book- 'Atomic Habits' credits this transformation to one individual and to one performance philosophy.

That individual is Dave Brailsford, the (then) performance director of England cycling team. And the performance philosophy that he introduced was 'aggregation of marginal gains'.

As James Clear explains in his book-
'The whole principle came from the idea that if you broke down everything you think of that goes into riding a bike, and then improve it by 1 percent, you will get an significant increase when you put them all together.'
What did Dave and his team improve ? Here are some of the examples:

1. Bike seat was redesigned to make it comfortable.
2. Riders wore electrically heated overshots to maintain optimum muscle temperature.
3. For better grips, rubbed alcohol on the tires.
4. Hired a surgeon to teach players a way to wash their hands so they reduce chances of catching cold.
5. Tested different types of massage gels for muscle recovery.

Image source:
This poster quite summarizes the concept of 'aggregation of marginal gains'. If you find a way to improve 1% of parts that make your field, aggregation of gains by end of the year would be staggering. Conversely, if your improvements are underwhelming, the gains are way under.

Incidentally, I was also reading Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs and one of the stories that established an equivalent of 'aggregation of marginal gains' philosophy in the field of software.

Ken Kocienda (author of the said book) was a part of the team that was tasked to build new browser by Apple (later called as 'Safari'). Of all things that Steve Jobs wanted in the new browser, the top-most in the list was performance. Jobs wanted the browser performance to be top-notch. One of the things that Ken was tasked to build was a tool that would assess the performance of browser against all the established parameters. This tool, that came to be known as PLT, Page Load Test was run everytime the code was changed and the new features were added.

PLT became a sort of conditioning coach for the software. It was almost a mandate to run PLT and ensure that no new change is degrading the software performance. Incrementally, every change was measured. Though it was quite difficult, given the complexity of software architecture, to ensure that every change improved the performance. Slowly but surely they reached their goal.

This method, Ken Kocienda doesn't call it in as many words as following 'aggregation of marginal gains' but in principle it was the same. They figured out  a way to measure tiniest of performance degradation and that eventually led to big gains in the end.

Do you relate to these examples ? Please do share any more examples on these lines.

Images source:

No comments: