How much should you pay for a car?

If you have a budget for a Hyundai car, don’t expect to get a Ferrari or BMW.

Same goes for a Software development

Wheather you are a experienced software development or just an intern, you are probably aware that creating an app costs both time and money. Business owner or entrepreneur doesn’t realize that maintenance and further development after an app is deployed can sometimes be quite expensive too.

It is not uncommon to see a gradual decrease in performance of your development team over time, especially after they meet the first or second deadline due to bugs, hotfixes and other issues.

If you have no technical background, than probably you will always be surprised that changing the position of an element or adding a new modal can take so much time. Especially, when it took only a moment a few months ago! Have you ever wondered what makes it so hard?

We’ve jot down the most popular reasons for the dropping productivity and increasing costs of frontend maintenance.

No Automatic Build Process and Deployment

The build and deployments refers to the process that converts files and other assets under the developers’ responsibility into a software product, it is the last steps before your app goes live. If they are not prepared in a proper, error-proof way, it might be expensive to avoid bugs and stay confident in the future.

No Tests

Automatic tests are the essential ingredient of refactoring and maintenance. It is an activity to check whether the actual results match the expected results. It involves execution of a software component or system component to evaluate one or more properties of interest.

Automatic testing also helps to identify errors, gaps or missing requirements in contrary to the actual requirements, this allows developers stay on top of it and focus on improving and adding features instead of being constantly afraid that they break something.

Fewer bugs, fewer crashes and better code quality are the benefits of automatic testing.

Poor Quality Code

If you take a look at code, you won’t be able to estimate quickly how good the project is. Understandability in code is for us humans. Computers don’t care how we write the code but we should.

Is any consistency over the repository. Are all the files structured identically? Are the indents consistent? What about semicolons? I know it might sound silly for a non-technical person, but the quality of your code is a very good indicator of the project’s status.

Architects don’t go off and just draw whatever they want on a blueprint without paying attention to the standards and practices of their industry. In the software industry, we need to establish good standards and practices that we can follow just like builders and architects follow.

No Structured JavaScript

There are a lot of smart folks in the JavaScript world that have been doing and talking about this for longer than I knew what a div was, there are lot of people who claim that world was a better place when there were no JavaScript frameworks. I don’t think so.

I have also seen apps written in Vanilla JS, without any structure. This is a very fast approach for reaching your MVP, but it will ultimately fail, and you will need to pay the technical debt as the code get more messier and harder to maintain.

I would always recommend using at least some kind of framework or library, like Vue.js or React.js.

No Responsive Web Design or Mobile-first Approach

The mobile-first approach is exactly as it sounds: designing for the smallest screen and working your way up. It is one of the best strategies to create either a responsive or adaptive design.

Even if it is rare today, there are still a lot of apps that don’t employ Responsive Web Design at all. When it comes to mobile, introducing mobile designs from the start can take less time.

A mobile first approach is perfect for structuring the CSS in your web app. If all the work is focused around mobile-first, it’s much easier to introduce tweaks and make sense of code that you have not seen for months.

No Readme

Readme.md is one of the key files on your project – you will need every time a new developer joins the team.

Code that you wrote 6 months ago is often indistinguishable from code that someone else has written. You will look upon a file with a fond sense of remembrance. Then a sneaking feeling of foreboding, knowing that someone less experienced, less wise, had written it.

Documentation allows you to transfer the why behind code. Much in the same way code comments explain the why, and not the how, documentation serves the same purpose.

A good documentation consist of (requirements, specifications, etc) and what it’s using (tools, dependencies etc). These are important in case it breaks - when I come back to a project I need to know how to get it working again if anything changed, how to use it, build it and eventually deploy it. If you don’t keep it updated from the very beginning, it can make your dev team spend hours on tackling problems somebody already solved earlier.

Summary

There can be lot more reasons why the maintenance of your app might be expensive, and you can actually prevent most of them from happening. The next thing is to make sure your team delivers top-quality code, regardless of how much time is left until the deadline, it’s better to take more time for shipping top-quality code instead of spending more time on fixing bugs.

Spending too much time on your app maintenance? Let’s cut down the cost of your fronted maintenance.