1. Introduction
From the recent Software-as-a-Service (SaaS) era, software development faced a challenging decision: create generic software that enables the users to define their own product line to use, or develop a software that guides the user to a certain way to accomplish tasks?
Thus, on one side, we have software providing multiple generic ways for the user to do a task. However, on the other side, we have software providing a specialized workflow for the user to do the same task. The pros and cons of these strategies are the basis of the debate about non-opinionated and opinionated software.
In this tutorial, we’ll investigate the concepts of non-opinionated and opinionated design. First, we’ll see a brief review regarding software design that led to our target concepts. So, we’ll understand the concepts of non-opinionated software. Next, we’ll see how is the design of opinionated software. Finally, we conclude the tutorial with a systematic summary.
2. How Did We Get Here?
Before the cloud era, software solutions were typically negotiated as simple products in a store. It means that, in this scenario, we choose a product, pay for it, and use the software as we wish.
The described model, for sure, still works nowadays. However, it does present some potential pitfalls. For instance, sometimes, one-time-buying software does not receive relevant updates. So, the users must keep using a deprecated solution for a long time (till buying a new version software license).
Moving forward in time, the rising of the cloud era brings new models to negotiate software. Now, it becomes viable to sell software on-demand, providing both the software itself and the infrastructure to execute it. The software got very dynamic, with solutions hosted in the cloud and being used and updated everywhere at any time.
This movement became known as the “as-a-Service” model. In our particular case: Software-as-a-Service.
This model led the industry to rethink how to provide a software solution to their customers. Make a software workflow more flexible or efficient? Sell generic services or specialist ones? All these thoughts permeate the concepts of non-opinionated and opinionated software.
It is relevant to note that the concept of opinionated historically exists and fits in different scenarios (for example, in the context of programming languages). But, the recent trends in software development warmed up this discussion.
3. Non-opinionated Design
The main idea around non-opinionated design is that the system users have the full ability to make their own decisions. It means that, usually, the system provides several ways to accomplish a task, and the user can choose the best one according to the problem and context.
The keyword of non-opinionated solutions is flexibility. By providing multiple manners to accomplish tasks, non-opinionated solutions trust their users in decision-making. Thus, there are no global right ways to do things, but actually one best-fitted way according to the user judgment and resources.
However, having great flexibility to deal with brings some challenges too. One example consists of the spreadsheet editors. Typically, these programs enable users to create different structures to keep and process the same data. So, adopting a non-efficient spreadsheet can turn the work much more costly when compared to a more efficient one.
Similarly, bad decisions when developing software using a generic programming language, such as PERL or PHP, can lead to intricate workflows in the final software.
In summary, employing non-opinionated solutions means facing multiple branches on the road, all leading to the same place. So, the better choice is the one that fits better to the available resources.
The following image intuitively presents the central idea behind the decision-making when using non-opinionated software:
4. Opinionated Design
Generally, we can see the opinionated design as an oracle that indicates the right way to accomplish tasks. So, opinionated solutions provide the resources and clear signs of how is it expected to use them.
However, this characteristic does not mean that opinionated solutions always offer a single manner (the “right” one) to do things. Actually, users typically can adopt other workflows than the advised one. But, doing that, probably the user will face difficulties and potential problems to accomplish tasks.
A significant challenge regarding opinionated design is evaluating if a problem fits the solution. So, if the problem matches with the solution resources and workflows, choosing opinionated software boosts users to solve problems fast and with outstanding quality on the final result.
Otherwise, if the problem doesn’t match the solution, the better choice is to select another opinionated solution (that fits better) or a non-opinionated one.
A famous example of opinionated solutions is the wiki pages. Wiki is an opinionated design to update content on a web page without (or few) knowledge of HTML and CSS. Thus, if the aimed webpage fits on a wiki page, it could be much simpler and fast use it instead of developing the entire page source code.
Regarding programming frameworks, in turn, an example of opinionated design is Ruby on Rails.
In short, the opinionated design is analogous to traveling a road with multiple traffic signs in a rented vehicle. Thus, following the road is very simple, but exiting it might be a disastrous decision.
The following image depicts the concept of opinionated design considering our intuitive example:
5. Systematic Summary
In the previous sections, we investigated the non-opinionated and opinionated design regarding how the solutions interact with the users.
In summary, the main difference regards flexibility. The non-opinionated design promotes different ways to accomplish the same task. The opinionated design, in turn, typically presents a “right way” to accomplish a task.
In this scenario, flexibility may be an advantage or disadvantage. The main advantage is enabling the users to make their own decisions according to their resources and context. However, making bad decisions can compromise the performance of an entire system or process.
The following table compares some characteristics and presents some examples of non-opinionated and opinionated design:
Non-opinionated
Opinionated
Keyword
Flexibility
Guiding
Regarding the User
The choices are in the users’ hands
The design indicates the “right way”
Software Examples
Microsoft Excel; Eclipse IDE
Wiki systems; Holacracy
Programming Language Examples
C; PERL; PHP
Ruby on Rails; Go
Finally, it is relevant to note the existence of a golden mean between non-opinionated and opinionated design. It can be achieved by providing high flexibility to the users while defining strong conventions to accomplish tasks. In such a scenario, users have the “right way” to do things but can tackle the particularities of their contexts and problems.
6. Conclusion
In this tutorial, we learned the concepts of non-opinionated and opinionated design. At first, we got a brief context about the recent discussions of these designs. Thus, we explored the non-opinionated design. Then, similarly, we investigated the opinionated design. Finally, we overviewed and compared the concepts in a systematic summary.
With the most recent business models in the technology and software world, the discussion about non-opinionated and opinionated software became a hot topic. Naturally, there are different advantages and disadvantages regarding each one to be considered. However, at the end of the day, adopting one or another will depend on the users’ objectives and the requirements of the tasks to be accomplished.