Battling Code Entropy with Strategic Development Principles
Summary
By establishing and maintaining strategic development principles your software team can build products and platforms that better resist the inexorable advance of software entropy. Holding the line on these principles requires strong organizational discipline, but the long-term payoffs can future proof your product and platforms and prevent tech debt overhang, thus accelerating your pace to product-market fit. Strategic development principles guide decision making within the scope of your software development organization. They are updated iteratively as your team continues to learn.
Entropy Happens
“Just as the constant increase of entropy is the basic law of the universe, so it is the basic law of life to be ever more highly structured and to struggle against entropy.” ― Václav Havel
Some folks love to talk shit about other people’s code. Like a Monday morning quarterback, they lack deep situational context and have the overconfidence to think they could do better. They wonder what kind of knucklehead wrote the code and criticize it, typically without investing in the deep techno-archaeology required to understand the hard decisions made under multiple constraints. The reality is likely that the maligned original coders had great intentions, imagination, and hope for their new software project to be a turning of the page, imagining a more modern and maintainable system. But over time, the effects of entropy crept in. Even the most talented teams often find their code and processes slowly devolve into a state where refactoring becomes unthinkably complex and too risky or expensive to invest in.
If entropy is inevitable, how might we slow its effects? How do we learn from the challenges of our coding forebears to create a better destiny for your product and organization?
“It is easier to recognize other people’s mistakes than our own.” - Daniel Kahneman
Thinking about Thinking
Thinking slows us down. It shifts us from our default mode of operation to a more intentional mode. Slowing down is necessary if your team is expected to learn and refer back to strategy and principles in guiding their decisions and behavior every day. Like cooking your first batch of salsa verde, you have to refer to the recipe, take your time, and move sloooooowly. Your velocity is low and your quality will be highly variable. Over time, as you bang out batch after batch, you will begin to internalize this recipe and operate faster, with greater efficiency. Your intentional mindset, established through a slow, rigorous approach becomes your default mindset (what Kahneman calls “Cognitive Ease” in Thinking Fast and Slow).
Easing Into Moving Fast
Software teams are always rushed to make progress. At project outset, there are often firm standards, architectural rigor, and a vision for why this time will be different. Yet gradually, there is an erosion of the foundational principles which eventually become distant memories. Rather than progressing from slow and intentional to fast and disciplined, teams pivot their commitment to feature delivery at all costs. The tech debt begins to pile up…
Avoiding this fate requires discipline. Write down your development principles. Partner with stakeholders to arrive at a shared understanding that the sustainability of the code base over the long-term, driven by a commitment to principles, is integral to enterprise value. Demonstrate through practice and delivery that the value of a principled approach will net greater efficiency (measured by higher quality, faster delivery throughput, and a low debt-to-feature ratio) in the long run.
Intentional Mind to “No Mind”
Slow and intentional thought must precede a state of no mind. When I was in college I began a long exploration of martial arts. I discovered a book called Zen in the Martial Arts, and was inspired to understand what it meant to achieve mu-shin (no mind). I wondered why it would be useful to have a drained mind and why exhausting and repetitive training was a prerequisite to this state. It took me a long time to realize that by fully understanding the principles and baking them into my bones through rigor, that I no longer thought about them. I went from “paint by numbers” to automatic movement.
Software teams should expect a phase of deliberate thought and somewhat mechanical movement as they go through a learning curve on their strategic development principles. With practice they will speed up and move more fluidly.
Enter Flow
We can’t be operating off recipes and painting by numbers forever. Our strategic development principles should eventually end up on the bookshelf and be referenced only when we are helping coach folks or onboard new team members. We must find flow, individually first and then as an organization. Achieving a state of flow as a team requires time, practice, and cognitive space to get in the zone. We are happier, more productive, and more creative when we achieve this state. Thanks to the work done by Mihály Csíkszentmihályi, runners, fighters, musicians, climbers, writers, and software engineers have learned to seek and appreciate this state. Without flow, we operate in a clunky style where each step we take has to be considered. With it, we are happier, more productive, and more creative.
Discipline is a Prerequisite to Flow
People find flow only after lots of hard work, starting with the basics, drilling repeatedly, failing, correcting mistakes, slowly finding the path of greatest results, and then reducing friction to find efficiency. Drilling the basics assumes principles, emerging from a learning organization, are written down clearly and coached. Your strategic development principles, practiced with rigor, will provide a pathway for your organization.
“Discipline equals freedom.” - Jocko Willink
Drive Awareness & Delegate Ownership
Ensure everyone on the team understands and internalizes the principles. They will shape behavior, cause the team to slow down and apply a long-term mindset with a goal of future-proof products and platforms. By establishing an ownership mindset across the team, each person should feel empowered to contribute to improve them and help their peers understand their purpose and value. Your retrospectives should consider how to improve these, over time, driven by team input.
“Festina lente.” (Make haste slowly)