Flexibility vs Complexity: Open/Closed Principle
I remember the first time I read about the Open/Closed principle (OCP) in college. I was amazed on the creative use of abstraction and inheritance to attain this. It was the first time I viewed software design as a jigsaw puzzle where one can just find the intricate way to fit the components together to build the finished product.
OCP is one of the underlying principles that make software development easier.
For instance in Android development framework, creating an application involves extending various components like activities and services. This allows developers to focus on the business logic without dealing directly with the internals of Android process management (and other hardcore OS stuff I have no idea about). The framework allows developers to craft whatever they want to without changing any of its existing code.
Wouldn’t it be great if our software adhere to the principle such that we won’t have to modify our code with new business specs? OCP for the win!
The open/closed principle isn’t always pragmatic.
Working as a software engineer for a while, I now take this principle with a pinch of salt. Making software flexibility comes with a cost: complexity.
As an engineer, theory is foundation. But there’s just a certain amount of theory you can take for you to make things work; if you stretch out the theory to reality, you’d end up with analysis paralysis. You would be spending way too much time designing the software which could have been used in producing the working one.
I’ve done a number of features where I’ve put my heart out in designing that feature are flexible as possible only to realize that I never went back to that piece of code. What could have been done in a straightforward manner inside one class was decomposed into several layers of abstractions which is tedious. Have I mentioned that you’d eventually stare at your favorite IDE thinking about what to name your next class?
Also, business requirements will always find a way to sabotage your software design in unexpected ways. You wouldn’t be able to anticipate them all.
So what now?
As I mature in my profession, I learned to evaluate which code portions are likely to change in the future. If you’re lucky, the stakeholders would drop hints for future changes — saying that they’d want this feature for now but would be extended or changed in the future.
Sometimes, you would have to anticipate the possible changes yourself especially when integrating with third-party services or using quick-changing technology.
The unfavorable case that could happen is a change on the business requirements which has a huge impact on the existing architecture. During my junior years, these changes would slightly disappoint me; now, I’m embracing them.
Nonetheless, this is where skills in requirements gathering come in — you’d want to get into the stakeholder’s mind on what he’d see the future of the software. If this portion is likely to change, then you’d want it to be more flexible under reasonable bounds.
A good software developer balances the scale of flexibility and complexity
With great flexibility comes great complexity.
I guess what I’m saying is that you don’t always have to design the system to be flexible as it consumes resources. A good developer would have good judgment whether to spend more time in making the code flexible or to just go with the simple and straightforward approach.
Lastly, the next time you have to modify your app’s architecture to in response to a business logic change, don’t feel too bad. In this world where everything is fast-paced, it’s always good to wear your agile suit.
