What a cartoon taught me about software
Each Sunday morning, my son and I eat 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 – a continuation of the original Dragon Ball and Dragon Ball Z series.
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 — you have been warned!
In the show, the character Beerus, who is introduced as a total badass, 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 its own god of destruction. We had some clues before, but it becomes increasingly obvious that Beerus is really bad at his job!
Casually destroying planets and sleeping for decades at a time placed his universe second from last in the 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.
In projects past, I liked to perform a weekly ritual where I review sections of code with the intent to destroy them. Not to break the codebase or for any malicious reasons, but to remove redundancies and 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 thousands of lines of code from our projects, maintain the same build times (even with new features being added), and make incremental performance improvements over time.
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:
If you found this valuable or entertaining, please follow the blog, and I’ll continue to post more tech goodness. Thanks for reading!
