Why are highly opinionated people viewed negatively

What is opinion-bound software?


When a framework has an opinion, it locks you down or introduces you to how to do it.

Example: Some people believe that a template system should not provide access to custom methods and functions because the system remains open to returning raw HTML. A sensitive framework developer therefore only allows access to data structures. The software is inherently restrictive and encourages the designer to do things their own way.

Another example (from the signal link) is the wiki. The wiki designers had many opinions. They thought HTML was too complicated for people to write, so they came up with the idea of ​​updating content in a more natural way. They also stripped it of the fancy design because they felt the focus should be more on content than design.

Apple has strong opinions when designing its products.

Software design without an opinion is more like PERL / PHP. It enables and trusts the developer to make the right decisions and gives them more control.

I would also put Microsoft in the column with no opinion. A good example of a Microsoft framework that has no opinion:. Opening the CLR and specs opened them to all kinds of languages ​​and implementation styles.

Opinionated software means that there is basically a way (the right way ™) Doing things and trying to do differently will be difficult and frustrating. On the other hand, do things correct ™ can make it very easy to develop the software as the number of decisions that you make is reduced and the ability of the software designer to concentrate on making the software work is increased. Well-made software can be great when it's well-made, when your problem fits well on the solution. It can be very difficult to resolve the parts of your problem that are not associated with the tools provided. An example of this would be Ruby on Rails.

Non-opinion-bound software, on the other hand, allows the user (developer) a lot of flexibility. It does not prohibit one method of solving a problem, but rather provides flexible tools that can be used to solve the problem in a variety of ways. The downside can be that the flexibility of the tools can make it relatively difficult to develop a solution. Much of the solution may need to be hand coded by the user (developer) as the framework does not provide enough help. You also have to think a lot more about how to deploy a solution, and mediocre developers may get worse solutions than if they went with software with a certain opinion. PERL is probably the classic example of software without an opinion.

My ideal is a non-opinionated framework, but one with strong conventions. I would put ASP.NET MVC in this category. In reality, all software is to some extent an opinion (though maybe not PERL). MVC has strong conventions in which to choose the model, but there are many different ways to solve problems within those conventions. Some of these possibilities can even damage the model. However, correct use in accordance with the conventions that develop in such a framework can be a real pleasure.

It's basically software that works the way the writers think it does, rather than trying to please everyone. That means a lot of people won't like it, but those who do will love it.

Rails is probably the canonical example of an opinion-bound framework: they do things their way and everything goes smoothly. If you don't, you will be in pain. But that's fine - if you don't want to do things your way, you don't want to use Rails.

For the sake of balance, I'll provide a (more opinion-based) description that is more favorable to the opinion-forming approach (as opposed to some of the other answers).

Opinionated frameworks provide a "golden path" that is supposed to be the best course of action for most people and most scenarios (in the eyes of the authors).

However, this does not necessarily mean lock-in. This means that extra effort may be required to do things differently.

Less-minded frameworks offer a number of different options and leave it up to you to decide.

Opinionated frameworks usually relieve the developer of reinventing the wheel or rethinking the same problem over and over, thus helping to focus on the real problem.

In the open source world, you can find a lot of opinion-based but competing frameworks so you still have a choice. You just have to choose your own golden path.

Opinionated software is built and designed to make it easy to do things a certain way. Certain design patterns are preferred more than others. In doing so, it is difficult to deviate from the style of software development for which it was designed. Another way of putting it is that it prefers "convention over configuration". ie the configuration options are very limited as the software handles many configuration aspects. Opinionated software is usually faster to master when the assumptions are understood.

Unopinioned software, on the other hand, makes few assumptions. As a result, unrevised software / software development frameworks often have many configuration options. A developer usually has to make many decisions about different aspects of the software. Different tools are often developed to make it easier to deal with these enormous possibilities. Example: Visual Studio .NET for .NET, Eclipse IDE for Java, etc. Mastering software that is not sacrificed usually takes longer than mastering opinion-bound software.

tl; dr :

  • opinion : e.g. Ruby on Rails . There is a particularly preferred way of doing things and you will receive a lot of support doing things that way. Doing things in other ways is difficult or impossible for some systems (Cassandra occurs to me).
  • Without an opinion : e.g. Pearl 5 . You can do anything you want, how you want, in any style. All styles are equally open, valid, and supported.

A lot of people refer to ASP.NET MVC as an "unopioned" framework, and I just wanted to weigh a few thoughts about them.

It's true that ASP.NET MVC isn't asking too much; You can use any persistence solution you want, be it Linq-to-SQL, ADO.NET entities, NHibernate, etc.

On the other hand, the MVC framework tends to favor "convention over configuration", to quote Phil Haack, who strongly suggests following the predefined pattern for localizing controllers, views, models and other code. While you can change this behavior, it is easier to swim with the current, and it won't be a problem for most people.

Around ASP.NET MVC there are also a lot of people with an opinion, which in my opinion leads to a lot of biased tutorials that insist, e.g. B. Cover unit testing and dependency injection. I am all in favor of good testing and the separation of concerns, but I perceive that such subjects are given a little sore throat, often before more useful fundamentals are covered.

Again, I have to admit that even in these areas, the framework is completely open to adopting the unit testing solution you want, as well as the dependency injection and mocking frameworks you use. I think this is another example of flexibility even within the "bible bashing" of unit tests, etc. that seems to be going on.

It is the number of conventions implemented in a framework and the number of decisions made.

For example, if there are 5 (or more) different ways to send form data to a controller action (which is the case in ASP.NET MVC), the framework seems to be pretty "unbiased" - the choice is yours!

However, if the framework only allows one way (either by disabling other methods directly or by strongly encouraging) (which is the case with Fubu MVC), then you can say that the decision was made by the framework, which will judge the framework .

The example that you will see a lot right now is the ASP.NET MVC framework. It's amazingly expandable, but that's the downfall in some ways, there's no meat. Do you want to access data? You have to write that yourself. Do you want AJAX? The same goes for.

However, since it's very extensible, if you build on it, you can turn it into an opinion-forming framework. This is what MVCContrib do, they give you specific methods to do things which means you have to write less code.

This means that if you want to disagree, there is often more work to be done than if you were to work on the vanilla version. However, this is an 80/20 scenario. If you got your opinion right, you will only want to differ 20% of the time and the other 80% of the time you will be highly productive.

We use cookies and other tracking technologies to improve your browsing experience on our website, to show you personalized content and targeted ads, to analyze our website traffic, and to understand where our visitors are coming from.

By continuing, you consent to our use of cookies and other tracking technologies and affirm you're at least 16 years old or have consent from a parent or guardian.

You can read details in our Cookie policy and Privacy policy.