Of course, we want the best of all worlds. We want our code to be clear and performant and extendable. But what happens when benefits are at odds with each other? What happens when, for example, in order to gain some clarity and improve maintainability we have to sacrifice some performance?
Of course, the answer is “it depends.” These days performance is rarely the bounding issue. It’s much better to think about building code in ways that are understandable to each other than to try to be clever for the sake of performance, most of the time. There are exceptions, of course.
Trade-offs in any field are inevitable and it seems like understanding when making the right trade-offs is a central part of every aspect of software development.
Rarely is there a right way and a wrong way to build software and different developers have different impressions on how to build code, which is fine as long as we’re able to interface our work together. One way we can do this is to have a common set of practices that we apply when building software. This is not to say that there is just one right way to do something. Often, there are many ways to approach a problem that are equally valid but yield very different kinds of designs. Understanding these trade-offs can be greatly beneficial.
Every design has trade-offs, it has strengths and weaknesses. Every design or piece of code is open for extension in some areas but closed for modification in the others. When thinking about and discussing designs, I find it extremely beneficial to call this out so that other developers are aware of how a design or a piece of code conforms to the Open-Closed Principle.
The Open-Closed Principle states that “Software entities (modules, classes, methods, etc.) should be open for extension but closed for modification.” What this means is that we want to make it so that adding new features in the future does not require changing a lot of existing code and mostly involves adding new code. When I ask developers why this principle is important they immediately know, because changing existing code is error-prone and difficult. Instead, we’d like to add new features by simply adding new code. And we can do this if we build our software to support the Open-Closed Principle.
Understanding where a design or piece of code is open for extension or how to make it open for extension in various ways gives us a way of extending features in a system without degrading the design or architecture.
Our goals when building a system are not around coming up with the perfect design. Very often when we start a project we know too little about what we’re building to determine the right design. Allowing a design to evolve over time can be highly efficient and effective. However, in order for a system to remain maintainable, we have to be willing to continually improve the design, as needed.
To me, software development is all about making trade-offs. It’s all about coming up with the right abstractions that do the job but don’t do more than is needed.
Every decision has consequences and when building software, one makes literally hundreds of decisions a day that affects the outcome of the product. In order to do this efficiently and effectively, to make the right trade-offs, we must first of all be aware of our options and then we must understand the consequences of each one. Becoming informed may not cause us to take any actions differently than we would have before but at least it helps us understand our options.
Previous Post: « Pair Programming Pointers
Next Post: Complex Systems »