What a kid’s cartoon taught me about software
Each Sunday morning my son and I perform a weekly ritual of eating a societally frowned upon amount of cereal and watch 1 or 2 hours of cartoons. It is one of the activities we look forward to the most during the week. In the mix we watch Dragon Ball Super – which is a continuation of the original series of Dragon Ball and Dragon Ball Z.
My son loves it because it’s “awesome”. I like it because it harkens back to my childhood when I watched the original series and could explain my love for things as “awesome” without any additional elaboration.
I have to give spoiler alerts in case anyone reading this is thinking about watching the show.
In the show there is the character Beerus, who is introduced as a total bad ass, can destroy planets on a whim, and initially fights off all the protagonists with nearly zero effort. It’s fitting since he’s the universe’s GOD OF DESTRUCTION!
Of course our heroes prevail in some form and save the earth from being casually erased. After which we learn that it’s simply just Beerus’ job to destroy things. Seriously, how is that a job?
Later in the series we learn that there are 12 universes in total, each with their own god of destruction. We had some clues before, but it becomes more and more obvious that Beerus is actually really bad at his job! Casually destroying planets, and sleeping for decades at a time placed his universe second from last in mortal ranking (some arbitrary system to quantify the prosperity of each universe).
So what makes a good god of destruction? well it turns out the higher ranked universes have their Gods of Destruction work in harmony with the forces of creation in order to nurture and avoid destroying the good worlds and remove beings, societies, or worlds that pose a risk to the overall well being of their universe.
So how does this relate to software? A code base can certainly feel like an entire universe that we create and shape to our desires, but as it grows in complexity and size things will inevitably become problematic. Debugging becomes harder, risks for failures increases, and build times can steadily increase.
For our team I perform a weekly ritual where I review sections of code with the intent to destroy. Not to break the codebase or for any malicious reasons, but to remove redundancies, old unused code, discuss with teammates what is still being used, and flatten complexity where it makes sense. An hour or two a week was all it took to remove over 2000 lines of code from our projects, maintain the same build times (even with new features being added), and make incremental performance improvements over a couple months.
It may not be the most interesting or glorious work, but if you felt bored or unengaged before you might feel more like this next time you press the delete button: