Obsessing over balance isn’t something we tend to do in the tech world.
While most of us would agree that balance is important, few of us elevate it to a vital, everyday practice.
That changed for me after studying the ideas of John Wooden, a Hall of Fame basketball player and coach, and best-selling author.
Whether you like or dislike basketball matters little when it comes to leveraging Wooden’s wisdom.
Wooden was obsessed with balance.
He worked tirelessly to establish balance in his teams because he discovered that it was essential to winning games and championships.
Without balance, Wooden found that his players could not be quick, and instead would be rushing and hurrying, which caused mistakes that lost games.
In daily practice, Wooden inspired and coached his players to have physical, mental, and emotional balance.
He encouraged his players to balance basketball with schoolwork.
He sought a balance of different heights in the players on his teams.
And he designed his team’s offense and defense to include the right balance of skills.
So how does balance impact software development?
Let’s consider some examples.
Balancing Discovery and Delivery
Imagine that after delivering several new software features to production, you learn that customers either don’t use them or barely use them.
This can result from an imbalance between discovery and delivery.
Failing to conduct sufficient discovery about user needs can waste time, bloat your code base, and over-complicate your software.
Better balance between discovery and delivery yields less time blindly investing in speculative features, and more time:
- understanding what customers need
- quickly and cheaply validating or invalidating feature ideas
- instrumenting your software and studying usage metrics
In her excellent book, Continuous Discovery Habits, Teresa Torres wrote, “many companies put a heavy emphasis on delivery–they focus on whether you shipped what you said you would on time and on budget–while under-investing in discovery, forgetting to assess if you built the right stuff. This book aims to correct for that imbalance.”
Balance in Development
Many software teams resign themselves to dealing with a steady stream of defects.
This unfortunate situation isn’t inevitable.
It results from an imbalance between continuously checking that software works and making the software.
I love practices like Test-Driven Development (TDD) and Behavior-Driven Development (BDD) because they lead us to continuously balance checking and making software.
That balance provides better risk management, which is essential in the complex work of crafting quality software.
A Better Balance of Knowledge
Knowledge silos are another common problem in software development.
When only one person knows how to do something, and they either aren’t around or are busy with other things, you end up being stuck or only able to make slow progress.
Ensembling (which we typically do in duos, trios and quartets) solves this problem.
It leads to a better balance of people who understand the code and can safely change it.
(Ensembling addresses many more imbalances in software development, but I won’t get into that here).
Better Balance In Coding and Integrating
Another common imbalance in software development relates to integrating code.
When we don’t balance our time between continuously writing code and integrating it into version control, development gets slower because merges become more difficult and those difficult merges often cause defects.
Continuous Integration solves this imbalance.
It gets us into a steady, fine-grained balancing of making and integrating code throughout the day.
And once again, that balance yields faster and better software development.
Misunderstanding Balance
I once evaluated a large (500 person) team that had just spent 5 months writing new code and 7 months hardening (fixing problems and debugging) the code for release.
Spending that much time hardening their code was a tremendous waste of time, and the CIO asked my company, Industrial Logic, for help.
Our goal was not simply to produce an equal balance between making and hardening, since six months of making followed by six months of hardening wouldn’t have been any better for this client.
Balancing is not a phase.
We are not simply targeting equal time spent on balancing important activities.
We aim for continuous balancing.
For this client, we helped them learn practices like Test-Driven Development and Continuous Integration so they could achieve a steady, everyday balancing between making software and checking that it works.
Such practices can reduce hardening time to zero (or close to it).
Better Balance in Software Development
I’ve highlighted a few areas in which better balance leads to safer and speedier results in software development.
There are many more.
For example, I’ve experienced better results via continuously balancing:
- technical, product and design perspectives in product management
- making new code and mending old code
- building software and demoing it
- designing new features and improving the UI/UX of those features
- focusing on current work and focusing on future work
Quickness Via Balance
Coach Wooden’s favorite mantra was “Be Quick – But Don’t Hurry.”
Balance played a huge role in that mantra.
Without balance, his players and teams could not be quick.
And quickness was essential to winning.
Thus, he spent loads of time helping his players slow down, develop physical, mental and emotional balance, and learn how to distinguish between being quick and hurrying or rushing.
This wisdom is universal.
It applies to many professions, including software development.
My book, Joy of Agility, features many stories about balance, all of which exemplify a mantra I called “Be Balanced and Graceful.”
I wonder what would happen if we in the software field obsessed over balance on a daily basis the way Coach Wooden did?
I’d be curious to hear your perspective and experiences with balance in software development.
