Changing Javascript framework: 4 questions to ask yourself before doing it.

With new framework options always on the horizon it pays to make sure our upgrades are well justified. New frameworks don't solve systemic issues. To make sure we're upgrading for the right reasons, we should ask the right questions.

Javascript framework

“What good does it do you to go overseas, to move from city to city? If you really want to escape the things that harass you, what you’re needing is not to be in a different place but to be a different person.” – Seneca, Letters from a Stoic
In this letter, Seneca was highlighting that running from a problem, does not solve it. You must be careful to understand that where you’re running from might not be the problem. The problem might even be you (in this case, your team/business). Before we make that leap and change where we are, we need to address ourselves. And our own potential shortcomings.
 
There comes a time with our software teams where a thought flashes through our mind: “Should we change framework?”

This thought can come from framework envy. It could come from a longing for change. Or the thought comes from a need to deliver genuine business value. And moving framework helps with this. The latter, unfortunately, is less likely. But hopefully, it’s the real reason for making the change. 
 
Often we make emotional decisions and justify them with logic. How often do we hear “But it was 50% off! I had to get it!”. That’s an emotional decision justified with logic. If you never needed the clothing item in the first place, you’ve spent money. Not saved it. If we don’t address our needs/problems, we can’t access our decisions.
 
Cynicism aside, moving framework can be a good thing. But there are some things we want to ask ourselves first. Doing so ensures that we’re doing this for the right reasons. And that in 6 months or a years time, that we’re in a better position than we currently are.
 
Some questions that we could ask ourselves are…

1. Do we currently have good test coverage?

Tested code isn’t always good code. But tested code is often simpler.
 
Testing is an area we may want to tackle before considering changing framework. But, there are many reasons we don’t write test code:
  • Lack of management/product buy in – The team around us doesn’t “believe” in testing. They don’t think it will add value in the long or short term.
  • We don’t have the technical architecture – The code base is untestable. Testing the code would mean pulling bits out, testing them and putting them back in. It would be a big investment upfront to ensure the code is testable.
  • We don’t have the knowledge – The team doesn’t have the knowledge to put in place. So we need to invest in training, pair programming or knowledge sharing.
  • We’ve decided against it – In your scenario, you’ve investigated testing. You’ve given it a real shot. And you have a very strong business reason to not test your code. Note: I’m yet to see this scenario in the web development world.
Often testing can make a huge impact to our codebase. It can make it simpler, cleaner and faster to develop on. Framework upgrading might not help us increase test coverage. It could be testing is a better area to focus on. After all, we don’t want to end up with another untested codebase.

2. Have we utilised our current framework?

Each new framework released is usually based on the ones before. Each framework learns from the successes and failures of its predecessor.
 
We want to ensure that the features we get from the new framework are available in our current framework. If they are, or if they are in some manner, we need to understand why we’re not already leveraging them.

3. Do we currently have low complexity?

Code that is simple and decoupled gets written when you make a commitment to quality. When you commit to going through several iterations of code review. Quality code is the output of (amongst many other things) knowledge, passion and time. All of which can be manifested without changing a framework.
 
If your current app has high complexity at the moment, we should analyse why. Do we have the capacity to write low complexity code? Are we knowledgeable and well enough equipped to write this code? Could we invest in more training? A new framework still requires code. Yes, it might be shinier code. But are we sure that the new framework will guide us to good paradigms? Or are we better off practising a bit more and training our teams first?

4. Are we reviewing new stuff against problems with the old

Are our current issues with maintainability? If they are then we should not be looking at how fast a framework is to get set up.
Instead, we should look at how easy it is to maintain.
 
To do this, we should build a very complex part of our app in the new framework. Then from this, re-write it or upgrade it. When we go through this process we’re evaluating from the angle of our current problem. Building new code is always fast. Maintaining it is not. If we have a maintenance problem, it’s likely not the framework’s problem.
 
We should review the new framework against problems we currently have. Not problems we don’t have.
 

Question: What reasons have you taken changing framework in the past?

Lou Bichard
Latest posts by Lou Bichard (see all)
Posted on
Category: Uncategorized