This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: Continual Professional Development
Recently, I revisited Chris Zimmerman’s “The Rules of Programming,” a book that, despite being published years ago, remains remarkably relevant in today’s fast-paced technological landscape. This is the third instalment in a series exploring the book’s core principles and how they apply to the challenges faced by modern development teams.
I’ve highlighted some of the most impactful quotes from the book, offering my perspective on their significance and how they can inform strategic decisions within technology teams. The enduring value of these ideas underscores the importance of foundational principles in navigating the ever-evolving world of software development.
Code Reviews: More Than Just Bug Hunting
Code reviews are often viewed as a tedious chore, primarily focused on identifying and squashing bugs. While finding defects is certainly a valuable outcome, the true power of code reviews lies far beyond that. Zimmerman astutely points out that the primary benefit of code reviews is social. As he writes:
Everyone writes better code if they know someone is going to look at it. They’ll follow formatting and naming conventions better. They won’t take shortcuts of leave tasks for later. Their comments will be clearer. They’ll solve problems the right way, not with hacks and workarounds. They’ll remember to take out temporary code used to diagnose a problem.
This highlights the importance of fostering a culture of peer review, where developers learn from each other and collectively elevate the quality of the codebase. It’s a powerful mechanism for knowledge sharing and ensuring consistency across a project, and a crucial element of a healthy development workflow.
The Perils of Error Handling
It’s easy to overlook the importance of robust error handling, especially when under pressure to deliver quickly. However, neglecting error handling is a recipe for long-term instability and maintainability issues. Zimmerman’s observation is stark:
Writing error-handling code to account for a mistake you made in calling the function is a sign that something is seriously wrong.
This isn’t simply about good practice; it’s a fundamental indicator of a deeper problem in the design or implementation. If you find yourself adding layers of error handling to compensate for potential failures in upstream components, it’s a strong signal that the underlying architecture needs to be revisited. Prioritising defensive programming and anticipating potential failure modes upfront saves time and frustration down the line.
The Value of Active Review
A passive code review—where the reviewer silently scans the code—is a missed opportunity. Code reviews are not a passive exercise; they require active engagement and thoughtful feedback. Zimmerman emphasises this point:
If the review is quiet—if the reviewer silently flips through a diff and occasionally grunts while the reviewee silently watches—then something is wrong. Yes, it’s still a code review, but you’re missing out on the real value that the review could provide.
A truly effective code review involves a dialogue, a collaborative exploration of the code, and a genuine effort to improve the design and implementation. This requires creating a culture where reviewers feel empowered to ask questions, challenge assumptions, and offer constructive suggestions.
Avoiding Unmanageable Functions
Functions with excessive parameters are a common source of complexity and fragility in software systems. They become unwieldy to use and difficult to maintain over time. Zimmerman describes this phenomenon well:
Here’s the thing about functions with lots of parameters—they’re unwieldy to use, and the unwieldiness grows over time. That’s because you’re fighting a positive feedback loop. The function that’s most likely to grow another parameter is the one that already has a bunch of parameters.
This is a classic example of the principle of least knowledge: functions should only need to know what they need to do, not about everything else. When a function starts accumulating too many parameters, it’s a strong indication that it should be broken down into smaller, more focused units.
Designing for Robustness
Preventing errors is always preferable to trying to recover from them. Proactive design choices can significantly improve the robustness of a system. Zimmerman highlights this key principle:
Despite our inability to make designs completely foolproof, every bit of foolishness we can prevent makes our systems more robust. So look for opportunities to eliminate failure cases from your design from the start.
This means anticipating potential edge cases, validating inputs, and designing for graceful degradation. It’s about building systems that are resilient to unexpected events and that can continue to function even in the face of adversity. This proactive approach to design reduces the likelihood of bugs and makes the system easier to maintain and evolve.
The Long Shadow of Old Code
The problem of bugs in legacy code is a persistent one. Even well-tested code can harbour latent defects that only become apparent when the system changes. Zimmerman reminds us of this reality:
I still find occasional bugs in code I wrote 25 years ago, and I’m pretty sure they weren’t the last bugs in that code. There are always more bugs hiding in old code, waiting for things to change enough that these latent bugs become active ones.
This underscores the importance of refactoring and modernising legacy systems. It’s not enough to simply maintain existing code; we must actively work to improve its quality and reduce its risk. This is a crucial aspect of long-term software sustainability.
Writing for the Future
Good code is not just about functionality; it’s about readability and maintainability. We should always consider the perspective of those who will be reading and modifying our code in the future. Zimmerman’s advice is simple yet profound:
To write good code, you need to think about the person reading it later. Don’t ask that person to juggle too many new ideas at once.
This means writing clear, concise code with well-defined abstractions. Avoid complex or convoluted logic, and strive to break down problems into smaller, more manageable pieces. This makes the code easier to understand, debug, and extend.
Simplicity as a Guiding Principle
When faced with a design decision, the simplest solution is often the best. Complexity introduces risk and makes systems harder to maintain. Zimmerman advocates for a minimalist approach:
The rule is simple—will this change make the code simpler and easier to understand? Will this code collapse more easily with the change? If so, create the function or employ the abstraction. If not, don’t.
This is a powerful principle that can guide decision-making at all levels of a project. Prioritise simplicity over cleverness, and avoid adding unnecessary complexity.
Ready to Apply These Principles?
These quotes from “The Rules of Programming” offer a timeless framework for building better software and fostering a more effective development environment.
At RJJ Software, I help technology teams apply these principles to achieve tangible results. From improving developer experience to modernising legacy systems, I provide strategic guidance to help your organisation thrive.
Explore how I can help your organisation achieve its technology goals. Visit my website to learn more about my strategic strategic technology consultation services.. I offer tailored guidance to help you navigate the complexities of modern technology and achieve your business goals