Good code is easy to change.
I read that somewhere in the depths of the internet about a year ago, and it’s substantially affected the way I code. It’s a pretty simple statement at face value, but it takes on a new meaning when read in terms of equivalence:
Good code is code that’s easy to change.
Put another way, if code is easy to change, then it’s good code. Does that sound like an overstatement? The more I think about it day-to-day, the more it seems like the most important factor for creating great software. Here are the four distilled reasons for this belief.
1. Requirements will change.
Users will request new features. Product owners will present a new design. Security vulnerabilities will be uncovered, and new standards for privacy will be demanded. Business logic will inevitably change in unexpected ways, and your code must be ready to reflect those changes on the fly. This counts even for libraries, as the languages they’re defined in introduce new versions and deprecate old capabilities.
2. Quick change is at the heart of software.
Can you imagine if Instagram could only release new software once a month? One of the most valuable factors of modern software systems is that they can be upgraded and released in very short timeframes if the process and infrastructure allow. But in order to make your release cycle as tight as possible, your code needs to be malleable.
3. Correctness isn’t actually that important.
The only contender against changeability that I can think of is correctness. Your code is no good unless it’s correct, right? Not necessarily. Highly-malleable code at least has the potential to be correct after a small amount of effort. Plus, code that’s easy to change right now will still be easy to change again two months later when the requirements change. On the other hand, correct code that’s hard to change will remain hard to change until you loosen it up with some refactoring.
4. Other principles usually boil down to changeability.
Separation of concerns, abstraction, loose coupling, don’t-repeat-yourself—all of these are patterns that make your code easier to change. In general, they ensure that any change you need to make will be (mostly) bounded within a single component.
So while it’s important to familiarize yourself with these concepts, it’s more important to think about why you’re using them in the first place. Keeping your code flexible using these patterns will make your life, and your fellow programmers’ lives, much easier down the line.
The corollary of this is that good code is changed until it is no longer good, thus are software environment is dominated by code that cannot be safely changed (i.e. bad code).
Comments are closed.