How to Avoid High Maintenance Cost on Your Frontend

There are two kinds of legacy projects. Some of them will allow you to just sit down and get on with your work. These are both maintainable at a reasonable cost and they are a positive experience for your developers. The other kind is the one that an army of tooled up devs must enter into and spend weeks working on, trying to tidy them all up. One man is not able to do it - anything he or she touches there, fails miserably. So what are the differences there? Are there any common things that make one project cheaper to maintain than the other?

What makes maintenance expensive?

If you want to see a more extensive list you can check it out here. Below you will find the three most important reasons.

1. No conventions. If your project does not have any conventions, it is extremely hard to feel confident on the inside. Developers are surprised by differences in syntax, no common approach and lack of integrity. This context-switching and greater mindfulness negatively influences their effectiveness.
2. No tests. Tests are the one and only thing that can give your developers confidence in what they are shipping. Without automated testing the team is not able to provide you with proper quality in a reasonable time span. Skipping tests now will cost you double the price when you eventually decide to carry out some maintenance and reworks.
3. No structured JavaScript. This is common for web apps to start very plain, with a rather easy and simple UI. A lot of teams decide to skip any JavaScript frameworks at this stage and stick with jQuery “for now”. Feature by feature, animation by animation and dynamic element after dynamic element the size of the jQuery code increases. And then, in this one particular moment, it becomes the spaghetti code which is impossible to maintain. That’s why, I’d rather recommend to stay consistent with the selected JavaScript framework from the very beginning. I can’t imagine a situation when a team skips Ruby on Rails for plain Ruby and says “Let’s add Ruby on Rails later when we really need it”.

How can you, as a project owner, avoid this?

1. Hire a specialised and experienced frontend team that will provide you the quality you need. Don’t insist on skipping tests in favor of the deadline - you will pay for that later!
2. If you don’t have the resources for a full-time frontend team, engage at least one dedicated frontend developer for the very beginning of the project to make sure that your CSS structure, conventions and JavaScript frameworks give a good foundation for your full stack developers later. It is a good investment.
3. Think about the future. In a reasonable manner! First of all, don’t underestimate the power of mobile and think mobile-first from the very beginning (unless you have a good knowledge about your users and the fact that they won’t use your app on mobile). Second, think about how dynamic you want your page to become. Maybe it is worth focusing on building Single Page Application from the very beginning? Or perhaps you know that the number of dynamic elements will increase slowly rather than exponentially?

Wrap-up

High maintenance cost may keep you wide awake at night. To avoid this nightmare to come true follow these few simple rules. With the support of a frontend specialist from the very beginning chances are you will not have to waste budget on unnecessary spending later. You can protect yourself from incurring loads of technical debt in places where it might be expensive to pay off. And don’t treat frontend as addition to your backend. Keep in mind that frontend sells, frontend converts and frontend is the first thing that your user sees. Sit on top of the giants and don’t experiment if you don’t have the resources.