Framework Compass Chart
I hate the “JavaScript fatigue” expression. As I stated in a previous story I think that right now as JavaScript developers we are in one of the most lively communities out there. We have a lot of power with React, Angular, Vue and so on. And it’s all within our grasp. We just need a npm i yet-another-framework and we’re ready to go.
But, like Peter Parker* says…
With Great Power Comes Great Responsibility.
What is our responsibility as developers then? I think that we should choose the right framework for our new shining project. Or to say it in a better way…
We should choose a good framework, in a right way.
Let’s focus on the word good. What does it mean to have a good framework? It simply helps dev teams to get things done. What I mean here is that our purpose is not to find the perfect framework, because it doesn’t exist. So we need to choose a tool that is just Good Enough for that use case.
Ok, now the hard part…
What does it mean to choose a framework “in a right way”?
I started asking myself “Is there a better way to make decisions out there for developers?” with a focus on decisions about technology stack o architecture. How do developers choose a framework? Usually, they analyze the functional requirements and they choose the framework based on their skills. Or they just follow the Hype!
But the framework is most of the times the first critical decision that every team makes, and it’s not a decision that should be taken lightly. The wrong framework can sink any project, even if the team is highly skilled.
An important part of every software that is often underestimated is the Non-functional Requirements (NFRs). If functional requirements describe what a software must do, the NFRs describe how to do it. And they are a fundamental part of every project. Examples of NFRs are Testability, Velocity, Durability and so on.
Different NFRs that can drastically change the framework to pick. And this kind of topics is most of the time totally skipped when choosing a framework. Thus, I created a way to make people talk about these frameworks in a standard and more pragmatic way.
Introducing the Framework Compass Chart…
It’s not easy to make decisions about non-functional requirements. Many of these factors oppose one another. A framework that guarantees to our team Velocity can have a low level of Testability. So how can we decide between Velocity and Testability? Let’s put them on a Radar Chart!
The first thing to do is to create the axis of your chart. The dev team should identify five or six non-functional requirements and put them on a radar chart.
Use the brainstorming technique that you prefer, I suggest something with a divergent thinking session and a convergent thinking session.
Now it’s time to fill the chart. For every NFR the team picks a value from 1 to 5. This value is the importance of that NFR for your team. A good way to define these numbers is to work as in a Planning poker meeting.
There are no rules about the values that should be put on the chart. Just consider that the perfect framework does not exist, so to put the maximum value for every NFR it’s quite useless. Remember that architectural choices are often a tradeoff of these NFRs, so in order to be useful, the compass should reflect the real needs of the projects. If a team needs Testability, probably they should “exchange” it with a lower Velocity. This quote explains why this could be a very delicate topic in a team.
Developers understand the benefits of everything and the tradeoffs of nothing! — Rich Hickey
As the name suggests, this chart should be used as a compass. For any Framework that a team is evaluating, they should check if it matches with our NFRs.
I witnessed that keeping the discussion about the chart helps developers to change their way to talk about frameworks. Before the Compass, they used expressions like “I favor React because…”, now they say “We should stick with React because we said that Testability is our top priority”. These conversations are safer because they are about the value that their code should bring to the project.
So, is this the right way to choose a Framework?
I find this exercise very useful when a new team is formed. It helps to create a strong sense of alignment. But a tool alone is never the solution, the real solution is the principles and the process that is behind the tool itself.
So, in the end, the right way to choose a framework, or to make any other kind of architectural decision, is to consider all of the NFRs and to find a way to let the teams decide the useful tradeoffs.
[*] It’s not entirely true that the famous quote is from Peter Parker… :D
Update: I talked about this format in Vienna for the local JavaScript meetup, you can see the video below
If you liked this post, you can buy me a virtual coffee ️😊
