DeutschSoftware developer Brent Roose recently wrote a blog post on what he calls “opinion-driven design”.
His point his that while a mindset of “high configurability and flexibility” is undoubtedly common when it comes to the development of software frameworks and libraries, it ultimately is also misguided in most cases.
In an attempt to both accommodate every possible use case and to remain in control (also known as the “Not invented here” (NIH) syndrome), framework developers tend to favour flexibility at the expense of simplicity and ease-of-use. In fact, it’s often an overemphasis on non-functional requirements (or: “ities”) such as interoperability, portability, or maintainability that gets in the way of solving a problem and creating value in a timely and cost-efficient manner.
In way, we often tend to fall for what could be termed “flexibility fallacy” while actually the most important of those ities often isn’t flexibility but rather comprehensibility: Code means communication. The ability to rapidly adapt to change and write code that can be easily modified and, in fact, deleted is much more important than the ever so elusive quality of reusability.
Brent suggests – and I couldn’t agree more – to write software in an opinionated manner instead: A framework or library doesn’t have to meet every possible or potential requirement and it doesn’t have to be the right solution for everyone. In fact, it could be said that if no one disagrees with you about a solution or approach you’re likely doing something wrong.
This opinionated approach to framework development and how that leads to better results probably is most famously embodied in the example of Ruby on Rails and the way that framework is promoted by its creator David Heinemeier Hansson.