So I just finished reading this great piece by Charlie Warzel. On the surface, it's about dealing with the pandemic walls we've all been running into over the last year. It's about how we shouldn't feel shame about the times we need to turn inward and reflect, about the times we feel depressed, about the times we need something different from the world than exuberant joy. On a deeper level, it talks about the cyclical nature of everything; the world doesn't have an eternal summer, it has seasons that nourish and feed each other, serving different and complementary purposes.
As I've aged, this has to me seemed a kind of fundamental truth. Everything gives and takes, comes and goes, is built and is destroyed, grows and dies. There's no permanence, no foundation; from what I understand, science has found that even the fundamental building blocks of the universe appear and disappear randomly and inconsistently, our laws of nature becoming obsolete the closer we look.
So let's take all that wisdom based on centuries of science and religion that a human could spend their entire lives contemplating yet never fully understand and apply it to the extremely unimportant stuff, like the process of software development.
What could seasonality mean in the cycle of software development? Spring, a time for tentative buds, seems like a time for user testing and experimental features. Once our spring testing shoots have found good growing conditions, summer is the time for rapid growth. Fall brings a hardening, securing our successful summer growth with scalable architecture and automated testing. Winter would be for cleaning up the mess we've left behind over the course of the last three seasons: killing failed tests in the code, removing dead features, turning months of detritus into fertile soil for the next growth cycle.
These cycles wouldn't necessarily be the same length or carry the same weight, but I think any engineer could see something like the above as an ideal way to build a healthy, long-lasting codebase, providing the right mix of expansion and contraction to keep everything healthy and balanced. I think most engineers at least would agree that it's an improvement on the constant spring/summer perpetual-growth-seeking cycles most software companies idealize.
There is no example in nature where a state of perpetual growth is healthy or desired. Famously, Edward Abbey wrote, “growth for the sake of growth is the ideology of the cancer cell.” Perpetual growth provides no time for rest, no time for reevaluation, no time for the soil to regenerate and heal. It's a recipe for burnout, burning out individuals, burning out organizations. Why do we choose burnout over balance?
I should probably wrap this before I start ranting about the demands of capital. Instead, I'll end on a call for deeper thinking in startup culture around how we build software. Let's push back against the demands of constant growth and find a way to build sustainably through the examples of the natural cycles we see all around us.