In the last few years, there has been a growing debate (argument) between two ideologies in software design: opinionated vs un-opinionated code. Generally, this argument divides along the lines of people that want an all-in-one framework (opinionated) vs those that want a do-it-yourself approach with smaller libraries (un-opinionated).
Personally, I sit on the small-library side of the fence. But more and more, I have a growing problem with the way libraries are presented to the public as “un-opinionated”.
MarionetteJS: A Highly Opinionated BackboneJS Framework
I recently heard someone saying that MarionetteJS is an un-opinionated framework.
I don’t believe this is true.
As the creator and original curator of MarionetteJS, I certainly did build my own opinions in to this library of tools to sit on top of Backbone. Yes, I did borrow some of these opinions from Backbone, directly. I intentionally wrote Marionette as a library of parts that can be used independently, or together to create something more. That philosophy and opinion came directly from Backbone. But beyond Backbone, I built my own opinions based on my own experience in to MarionetteJS.
I know some people are going to say that Backbone and Marionette are un-opinionated about architecture, and that I’m misunderstanding the point of calling them un-opinionated. I disagree with that conclusion.
I believe that both MarionetteJS and BackboneJS are very strongly opinionated about architecture and application level concerns. They both very clearly say architecture should not be dictated by a framework, but should be grown organically, as-needed.
If that’s not an opinion, I don’t know what is.
Marionette, Backbone, Underscore, jQuery – all of the little libraries that you are using on a daily basis, are all very opinionated. These are all flexible, bendable and reconfigurable tools. But that flexibility should not be confused with a lack of opinion. And yes, what these tools are opinionated about may vary, but none of them are un-opinionated.
Code Is Opinion
The core of my problem with “un-opinionated” as a label for any code, is the fallacy it spreads.
Whether or not you realize it, every line of code that you write has an opinion that has helped shape that line of code. The code is not only shaped by that opinion, but is an expression of that opinion.
It is your opinion that the variable should be named that. It is your opinion that the method should take these parameters, in this order. It is your opinion that the object should contain these methods, and perform this behavior. It is your opinion that the public API for this module should expose these methods and interfaces. The variable names, the method name, the object names, the types, the modules, the public API – all of it, from the smallest bits out to the code that other developers interact with – it is all laced with opinion.
Even if you are deferring your opinion to the style guide, guidance, or input of other developers, it is still the opinion of someone.
Making Implicit Opinions Explicit
It is our job as developers, to consider the next person that will deal with the code we are writing. Whether that person is on our team, is someone using an open source library, or is our own self in the near to distant future, making implicit opinions know is a very important task.
The best way that I’ve found to make these opinions known, is through documentation and examples. But I don’t mean API documentation alone. Rather, I mean a higher level of documentation and example, where the various parts of what we are building are put together for other people to see.
Write “Getting Started” guides and “How To” articles. Record screencasts of how you are using the various pieces together. Talk to other people and show them what you are doing so that they can help you with this. Find ways in which you can make your implicit opinions known. Make them explicit so that the developers who follow behind you will be able to understand not only your implementation, but also your intention.
Examining Your Own Opinions
The ability to make an implicit knowledge and opinions known requires the ability to examine to core of your own opinions and beliefs. Why do you believe that code should look that way? What experience and influence is hiding in that decision? Is that experience really going to apply here? Will that influence be left unchecked, or has it been thoroughly vetted to ensure it is valid here?
Making our own knowledge explicit is difficult, at best, because it can open us up to the possibility that we are wrong. No one wants to be wrong, even if we know we are. There can be pain and vulnerability in admitting that your opinion is based on incorrect or misapplied ideas. If you’re able to do this, though, the opinions that you espouse will have that much more power and weight, as they will have been tested against the opinions and experiences of others.
That doesn’t mean your opinions won’t change. They probably will, to be honest. But we have to be open to that possibility if we want our opinions to have any amount of influence.
For Others. For Ourselves.
The next time you find yourself thinking about your own code, stop for a moment and think about the implicit opinions you are stating in the code. Is there something that you are assuming in the way it will be used? Would the team you’re working with benefit from those opinions being made explicit? Would *you* benefit from this, in the future?
Making our own opinions known can be a critical part in the success of anything that we do, whether it is for the benefit of others, or for ourselves.