What Can Wilt Chamberlain’s Free Throws Teach Us About Software Development?
Wilt Chamberlain was the greatest basketball player who ever lived. His most notable achievement (in basketball at least) was in 1962, while playing for the Philadelphia Warriors he scored 100 points against the New York Knicks, a record that still stands today. Even more impressive that night was that Chamberlain, a player known for being a terrible free throw shooter, made 28 out of 32 free throws. The story of this game was recently discussed on the excellent “Revisionist History” podcast. In the episode, Malcolm Gladwell recounts how Chamberlain had switched free throw techniques and began shooting his free throws underhanded (sometimes known as a “Granny Shot“). Suddenly, Chamberlain went from a terrible free throw shooter to one of the best. He was now UNSTOPPABLE!
Except…not long after, he switched back to his old style of free throw shooting and his completion ratio tanked. He went from shooting 87.5% shooting underhanded back to shooting 40% overhanded. His only achilles heel had been his inability to shoot free throws and as soon as he’d mastered them he went back to the old way. Why would he do that? Well, Chamberlain put it this way in his biography, “I felt silly, like a sissy, shooting underhanded. I know I was wrong. I know some of the best foul shooters in history shot that way. Even now, the best one in the NBA, Rick Barry, shoots underhanded. I just couldn’t do it.” Even though all the statistics proved that shooting underhanded was the best way to go and even after he had seen the success first hand in his record breaking game he still chose to ignore it. On the other hand Rick Barry, the greatest free thrower of all time understood the advantage of underhanded free throws and embraced it to great success.
I felt silly, like a sissy, shooting underhanded. I know I was wrong. I know some of the best foul shooters in history shot that way. Even now, the best one in the NBA, Rick Barry, shoots underhanded. I just couldn’t do it.
This may seem unthinkable to many people but as software developers many of us do the exact same thing. I’m talking about creating and maintaining a culture of “Sustainable Code.”
What do I mean by “Sustainable Code?” Sustainable Code is a methodology that intends to build software using proven techniques to ensure a lower defect rate, faster turn around time on features, shorter regression test period and better work life balance for the team.
How is this achieved? There are a couple of core disciplines that over the years I’ve learned can make a huge difference when it comes to building a culture that writes sustainable code, I will be going into these in more detail in future posts.
These include unit testing, integration testing, automated feature testing.
Pair and Squad Programming
Working with another developer on a single development task or even having the entire team in a room working on a single ticket.
Sharing your work with the team and getting feedback.
Don’t get bogged down for weeks at a time working on a single feature. Write code, check-in and deploy often.
Close collaboration between devs, QA and business analysts.
We’re all one team, don’t just throw things over the wall.
Now, if you’ve been a developer any length of time you’ve probably run into every item in the list but based on statistics you most likely practice few if any of them. One study showed that TDD lowered defect rates between 40% and 90% when compared to non-TDD projects while only increasing development time 15%-35%. Even in the worst case scenario this is a net-gain! However, just like in the case of Wilt Chamberlain, most developers chose to ignore the stats and keep doing what they’re doing. Most developers balk at having someone review their code or think unit testing is a waste of time and don’t think they need it.
I’ll be the first to say that early on I HATED writing unit tests. I thought they were so pointless and just took time a way from “real development.” I didn’t want to do code reviews because in my mind I was a good programmer and I didn’t want someone else telling me how to do my job. But as I matured as a developer I came to embrace testing. It lowered my stress level when doing a refactor because I always knew I had the tests to rely on to tell me if I’d done something wrong. The same goes for code reviews. I now look forward to them because its a way to learn new ideas and gain new perspective. I get great feedback and the entire team has a better understanding of what each person is working on.
Most importantly though as our organization has adopted agile practices, I’ve realized that without these things we could not really say that we’re practicing lean. Gone are the days of multi-week regression cycles, hours long deployments, huge backlogs of defects.
As a developer. don’t be like Wilt Chamberlain and ignore proven practices because of pride or other reasons. Be like Rick Barry and use these practices to your advantage.