DEV Community

Cover image for Investing in the right technologies to avoid technical debt
Sunny Singh
Sunny Singh

Posted on • Updated on • Originally published at sunnysingh.io

Investing in the right technologies to avoid technical debt

This article was originally published to my newsletter.

There is a common joke in the JavaScript community that a new framework or library gets released every single day. True or not, it's funny because it definitely seems like that is the case. With so many new things to learn, how can you possibly keep up? Or should you?

A comic about a developer telling everyone to stop everything and move to a new framework because their current one changed slightly

Learn patience, not a new framework ⏳

I love keeping up with the latest technologies. In fact, I built a site called DevNews a few years ago in which I still use today for finding new tech and software related articles and products.

However, there is a big difference between reading up about a new framework versus actually investing time to learning and potentially even migrating your current code over to it. A lot of the time, it's not worth it because that framework becomes obsolete or even non-existent in a few years.

I've been bitten by this problem many times in the past, and the best advice that I can give is to simply be patient.

For any big projects that you expect to stay around for at least 5 years, you probably want to observe a framework's community long enough before making the decision to learn and use it. Consider the time that you put in to learning a specific framework or tool to be an investment. That return on investment should be a positive one.

The story of AngularJS and React ⚔️

Do you remember AngularJS? Many developers were using it around 5 years ago, and it was deemed the go-to framework for making a dynamic website or entire web app. It was even backed by Google, so what could go wrong?

Angular 2 was announced and it was completely different from the first version. In fact, backwards compatibility was not an available option early on. Thus the usage of React, a competing option from Facebook, grew.

I personally worked on an AngularJS project, but I never invested into it deeply. I was skeptical and continued to build my own projects the traditional way (a monolithic Laravel backend with a jQuery and Bootstrap frontend). Fast forward and I am now building multiple React apps.

I believe that this is the correct approach. Use the tools and technologies that work well for you until you know for sure that there is a better way.

Cool cool... but how do I know when there is a better way?

— Avid DEV reader

Ah, I'm glad you asked. I did an entire podcast episode about this topic! While I talk about React specifically, the principles (community, efficiency, and longevity) apply to any framework or tool. Recommend you check it out 👇

In general, a large community size means more resources available to you for debugging issues and finding accompanying libraries. Even in the case of Angular, there are still tons of resources out there to continue maintaining those projects.

Question: How do you manage to stay on top of technical debt, or how have you been bitten by it in the past?

Top comments (36)

Collapse
 
thebouv profile image
Anthony Bouvier

Learn all the things (that you want to learn).

I suggest people play with new frameworks, new tech, new languages.

Learn them, learn FROM them, make yourself overall better.

But that doesn't mean you have to shift your entire life over to them, refactor everything, and destroy productivity. And balance this with your life of course.

Don't get stuck in analysis paralysis on what to do next. Go with your gut. Learn, adapt, move on. Your cumulative knowledge will grow and you'll be a better developer/engineer/sysadmin/etc.

Collapse
 
donita profile image
Donita

I really love this article and insight. When I first started on my engineering journey, someone told me don't be invested in frameworks, they are forever changing. Know the fundamentals, everything else you can learn on the fly or even on the job. Not saying, you can't learn programming languages on the job as well, but it's a lot easier transition if you know the fundamentals and you're just coming behind learning the frameworks at your particular place of employment. That's why I don't really like companies that insist on hiring only Angular or React developers, as if JavaScript isn't the fundamental language behind it.

Collapse
 
sunnysingh profile image
Sunny Singh

Thank you Donita! I agree, fundamentals are way more important than knowing the trendiest framework.

Collapse
 
ssimontis profile image
Scott Simontis

I think there's no magical trick, it's the sum of all your experiences as a developer which guides your decisions. I have had to learn the hard way on this very issue. Fortunately, I had an architect at a previous job who suspicious of all new technologies (iirc he had a very successful startup and framework hype led to a major refactoring which brought the company down), and it really pissed me off at first when he told me that he didn't want any of this "crap" in our codebase. We both definitely could have communicated more neutrally on the topic, but in the end, he was right. Many of the libraries I wanted to use are no longer maintained. Sometimes I had absolutely no reason to pull in a tool, it was just shiny. I think NPM has made us all a lot more aware of dependency hell, although I don't think it's causing us to question our actions as much as it should.

Nowadays, I just pick things up that are intuitive to me. I really like functional programming, it seems very logical and it just clicks with my brain. It took me several years to get to he point where it licked; at first I was doing it because a lot of programmers I respected were dong it, and I wanted to follow in their footsteps. Eventually, I realized that I had slowly picked up enough over time that I was naturally coding according to FP principles without even having to think about it. Therefore, a lot of technologies that adapt FP concepts click with me and I am drawn to them.

While there are realistic questions that need to be considered with new technologies (the community aspect you mentioned probably the biggest one), you also have to remember to f*** all the haters. There's always going to be someone out there on the Internet waiting for a chance to crap all over your preferred technology. If it works for you, it works and that's all the evidence you need. I can't blame them for doing so, I have to admit that sometimes being a judgmental snob can feel pretty self-satisfying in the moment. At these moments, I have to jump back to my experiences with these individuals over the years and remember to keep an open mind. Not everyone does things the way I prefer them to be done, yet the sun still rises every morning and the Earth keeps spinning.

Collapse
 
sunnysingh profile image
Sunny Singh

100% agree with you Scott, well said! Experience is a huge factor in this because I learned a lot of these principles and the ones you mentioned from dealing with problems in past codebases.

And yeah, ignore the haters and definitely don't be one of them. Use what feels best to you and respect others' decisions.

Collapse
 
derek profile image
derek • Edited

How do you manage to stay on top of technical debt?

Quality unit tests with decent code coverage, keeping dependencies to a minimum and vetting them prior for community/financial support before installing/using. When dependencies are being used, I constantly check/scan/read the change-log and I make the effort to constantly update.

opinion: I really think the word choice of technical debt, emphasis on debt is the perfect name/term (naming is hard), because it really does accumulate compounded interest of pain over time; just like in finances if you let it accumulate too much you usually file for bankruptcy.

How have you been bitten by it in the past?

Kicking the can down the road, ie: we'll fix it in the next release/version

Collapse
 
sunnysingh profile image
Sunny Singh

Having good code coverage definitely helps with ensuring an upgrade won't break something critical.

And yeah, procrastination can kill maintainable software.

Collapse
 
edwinthinks profile image
Edwin Mak

I really like this article! Especially with the heading "Learn patience, not a new framework"

I suggest every developer to spend some time learning whatever technology they are interested in. I am a firm believer that a company should give their developers this space for creativity and learning. Although, I think it needs to be mentioned that it there is no promise that the learnings will be directly used in the company's business. However, there have been times that a developer on their exploration time brought some great new ideas & tools that were implemented into the business software.

In terms of introducing change in the business's software, I think it highly depends on the trade off between risk & reward. I usually inquire about what would happen if things go wrong with the change and what problems do we seek to solve making this change. For example, I would be more okay with adding a dependency than changing/adding the framework for a project.

My 2 cents :)

Collapse
 
sunnysingh profile image
Sunny Singh

Thank you, that means a lot. I'm quite proud of that heading honestly.

Completely with you on risk & reward. You don't want to introduce too high of a risk if the reward isn't great. This is why incrementally introducing changes makes for an ideal compromise, especially in preparing for an eventual framework change when needed.

Collapse
 
edwinthinks profile image
Edwin Mak

:). Looking forward to more of your writings.

I would also add that I think there is an unspoken amount of entropy that it takes to get new developers to utilize a new tool + practice. This should also be included in risk assessment of introducing a new tool.

One of the worst things that can happen is that your software is filled with various tools that various people. Bloat :O

Thread Thread
 
sunnysingh profile image
Sunny Singh

Either that or developers creating their own utilities that duplicate existing functionality, simply because they don't like the current solution or didn't know it existed. This is of course mostly a problem in larger codebases but still plays to your point, installing a library is simply step 1 to adoption/integration.

Collapse
 
xngwng profile image
Xing Wang

Sometimes it is also important to avoid grass is always greener syndrom.

It is not a technical debt just because you aren't on the latest hottest framework. It is technical debt when you didn't design your software well.

The reason that front end code change often is because, where every few years, the management or market pressure to need to do redesign, in which case, often times you have to rewrite the front end, since design changes will change all the code anyways. So front end frameworks changes often.

But for backend it is less change often. I remember I went to a startup meet up, and each startup talked about their tech stack, their front end may be refreshened, but their backend is almost always the hottest "framework" around the time they started. For example, companies that started in 2006 to 2010 tends to be ruby on rails, before that Php, after that, a lot of Node.js, etc.

Collapse
 
trendschau profile image
Sebastian Schürmanns • Edited

Agree, I made the same experience with a project that was migrated from JQuery to AngularJS and was updated to Angular just one year later, the ROI was super negative. And I face this problem everyday with older projects that use old tech-stacks. People always discuss about new technology, but in many cases it does not really make sense to migrate, especially if client does not care.

I myself used Vanilla JS for years because I did not like JQuery. I skipped Angular, tried React but did not really like and now I use Vue. So my receipe is:

  • Use new tech if you really like it
  • Use new tech for new projects
  • Think twice before you migrate an old project to new tech...
Collapse
 
tomavelev profile image
Toma

Too much focus on the technical stuff! No truly end user give a damn about design patterns, variable names, libraries and frameworks. The non-technical people, the ones that in the end pay for the technology want - ux, speed, simplicity, value (business logic) etc. Simplicity is the most complex thing.

Collapse
 
sunnysingh profile image
Sunny Singh

Totally with you, although I wasn't for a long time. It's hard as a developer to step away from the code to consider the bigger picture, but we really are just building software for other people. Providing them a good user experience is most important.

Indirectly, efficient developer practices allows building out good user experiences, but only until you get into diminishing returns of over engineering. I try to consider the ROI of an improvement in development workflow to the end user.

Collapse
 
jwp profile image
John Peters

Very good statement.

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao

I think to be slow and focusing on your fundamentals is more important than just picking up another framework.

Like for me GraphQL and Web assembly are great but I will just play around till I know this is good to switch over or till there are not enough developers for it which makes it expensive to maintain.

Collapse
 
sunnysingh profile image
Sunny Singh

Yep exactly. There is some stigma between developers to constantly stay up to date, but that doesn't mean you have to implement every framework that gets released daily into your project.

REST APIs will stay around for a long time and is still a safer choice. I do love me some GraphQL though, depends on the project.

Collapse
 
adipolak profile image
Adi Polak • Edited

Challenge everything! new frameworks are great, it's fun, they aim to fix issues that exists in other frameworks and make our lives better.

However, community matters, scale matters and framework maturity matters.
These 3 points are key to understanding if the new framework should be tested in production.

Some questions we should ask:

  • Is this framework actually help us solve one or more of our business cases?
  • Does it solves a bottleneck that slows us down?
  • Do I have the right knowledge in the team?

There are lots more questions that we should ask ourself before breaking everything and moving into using something new and unknown.

I do encourage everyone to learn and play with new tech! it's fun, it's educating, it keeps us curious and open-minded.
Create personal projects, demos, write about your findings, open tickets to fix bugs and stay active!

As it seems, life long learners is the best attitude for working in tech.
Along with empathy 🤗.

Stay humble, stay curious!

Collapse
 
sunnysingh profile image
Sunny Singh

This is an amazing response, I wholeheartedly agree with you. It's all about the balance between challenging current practices while healthily maintaining technical debt by tackling the 3 things you mentioned: community, scale, and maturity.

Collapse
 
steveblue profile image
Stephen Belovarich

“In fact, backwards compatibility was not even a consideration ” is not 100% accurate. NgUpgrade is a thing. There is at least one book about upgrading from AngularJS to Angular. Backwards compatibility wasn’t possible because of security holes in AngularJS which they took seriously at Google. But the Angular team at least provided a bridge for upgrading from AngularJS to Angular.

Collapse
 
sunnysingh profile image
Sunny Singh

I will make an update to the article to address this. Sorry for the misinformation!

Collapse
 
ryansmith profile image
Ryan Smith • Edited

I agree that it is important to be patient when it comes to new and exciting things. Junior developers may come onto a team wanting to use new tools, but the more senior team members may seem opposed to change. It isn't always because they are old, scared, or do not want to put in the effort. It is because they have experienced the pain of switching to something too soon. When you use unproven technology, there are risks. You will have to figure out issues that have not been answered by the community. If the community fades away, there won't be an abundance of answers out there. This can slow development time a great deal. You will not be faulted for sticking with something stable, but you will be faulted for choosing something new and running into problems delivering the project.

Using new tools also does not guarantee you won't run into the same issues. Using React will give you an effective way to render UI and manage state, which may solve some of your team's problems. If you are working in a legacy PHP application and there was a lack of team standardization, chances are you have spaghetti code where the back-end logic is coupled with the view, JavaScript, and CSS. It works, but it isn't pretty. If you start using React and your team is not trained on it, or it is not introduced into the application in an appropriate way, similar things are likely to happen. There would be changes in the build process, a change in the programming language, and a change in the structure of the application code. Not every developer is not up to date on the latest and greatest in the JavaScript world, so their solutions could create problems. You could end up a similar mess like the PHP app but in React. Other developers may feel like this new technology was supposed to solve all of the problems, but it is just a hurdle to productivity and another mess to deal with. That is how technical debt is created.

The other side of it is being too patient. Do not let highly-used, highly-rated, production-proven, and stable technologies pass you by. You may have chosen a tool 5-10 years ago and made the right choice, but sticking with it for new projects may also lead to the technical debt due to a lack of maintenance, support, and a smaller community around that technology. This involves analyzing when it is appropriate to move on to something new in an incremental way to minimize the risk and set your team up for success in the future. Re-writing your entire existing application is unlikely to happen, but you can get started in a controlled way.

Collapse
 
sunnysingh profile image
Sunny Singh

Not every developer is up to date on the latest and greatest in the JavaScript world, so their solutions could create problems.

Definitely something that I don't see enough companies consider when upgrading to new tech. It's important to offer proper education, documentation, and also architecture that allows any level of experience developer to jump in to the codebase with confidence that they're doing things "the right way".

Collapse
 
mccabiles profile image
Miguel

As a young developer, I always get caught up in wanting to learn the next new thing without really knowing the fundamentals. This was a great wake-up call for me to stay focused and to be good at what I know. Thank you for your insight!

Collapse
 
sunnysingh profile image
Sunny Singh

Super happy to hear that Miguel!

Collapse
 
matthewbdaly profile image
Matthew Daly

It's always worthwhile tinkering with a new framework when it appears. It'll help give a good feel for what it's good at, the problems you'll encounter with it, and when to use it.

However, the decision to use a particular framework for a non-trivial application should be made carefully. I'd never choose a framework I had little or no experience with for anything other than a small application, because you simply don't have enough information to decide if it's a good fit. For something small it won't matter, but for a large application you'll be maintaining for a while it will matter.

Collapse
 
mackignacio profile image
Mack_Ignacio

First React is not a framework its just a library unlike what Angular is. Angular is a complete framework with routing, material and other built in features. I like react but for small projects but for large projects I prefer Angular than React. Great insight but lack on research. Angular is better than react. Please see the new updates on Angular and you will be astonish on how Angular came to be.

Collapse
 
sunnysingh profile image
Sunny Singh

React is not a framework

I'm aware it's a UI library. I use the term loosely as many in the industry do because of the way real world apps are built with React Router, Redux, etc. Plus all of this is moot as semantics of what is considered a framework or library isn't the focus of the article.

Angular is better than react

I respect your opinion and I love what Angular, Vue.js, Ember, and other frameworks are doing. Framework choice is not a war and again goes against the point of the article.

Great insight but lack on research

I guess I'll take a compliment where I can get it.

Collapse
 
jwp profile image
John Peters

I've found that react only folks are the ones that love this library argument. But all that matters is load time and render time. Load times with lazy loading makes that point mostly a non argument.

Finally run time rendering times are about the same for both.