5 common issues that makes your web development slow and hard to manage

5 common problems in the software development process and how to avoid them.

At first, your app is fast, small in size, and easy to manage. However, with each month the application is slower, its size is growing and code management takes more and more time. Is there a way to improve that? Let’s walk through 5 common issues and how to fix them.

5 common issues

Developing a web application is a process that is a combination of tradeoffs, pressure, and everything we want to build “fast”. However, that process comes with a price – slower and slower the application, bigger and bigger the size, spending more and more time on managing changes. Here are 5 common issues that impact your web software development quality:

1. Include dependencies without analyzing them before their usage.
2. Ignoring predefined threshold for the maximum final package size.
3. Missing or poor loading and run performance monitoring.
4. Unreadable code.
5. Unclear defined requirements.

Include dependencies without analyzing them before their usage

Let’s include package A and we’ll resolve the problem. Quick and easy. Absolutely not. Before including any external dependency review the following points:

1. What is the dependency size? If you use npm packages use bundlephobia service to check the package size. Example for @sitelintcode/optimize-image-on-the-client-side package. However, double-check also on the original repository and check the distributable package size. There might be some differences between bundlephobia service calculation and real distributable package size.
2. When were changes last published? The last date change determines the freshness of the packages. At least, at some level of degree. You better avoid including very old packages that may not be up to date.
3. How long does it take to resolve the issue? When you find a bug, it’s good practice to report it to the author. However, check the list of previously reported bugs and feature requests and determine how long it takes from the date of request to the date of the published solution. You don’t want to wait a couple of years for the issue resolution.
4. How many items (bugs or requests for new features) are submitted? How many have been solved? How many have not been resolved? What is the date of the oldest unsolved problem? This will allow you to determine the average response to the questions asked, reported problems, or requests for new functionalities.
5. Check if the problem can’t be solved with a few lines of code. Often, there are already built-in methods (e.g. Date, Intl.DateTimeFormat) that can greatly provide the solution to the problem. You don’t need to attach a 0.5MB package just to calculate what day of the week it was yesterday. Besides, writing code makes your experience stronger. Note that this doesn’t mean always writing the code on your own. Just evaluate possibilities and then decide whether to use an external solution or not to use.

Ignoring predefined threshold for the maximum final package size

So you want to keep the application size relatively small, and you set a limit that you don’t want to exceed. How many times have you been in the situation: “Oh, I went a little over the size, but I will increase the limit and it will allow me to push things forward”? Well, no. If you allow it once, the next time will be no different, and the general set limit will tend to ignore it.

Be disciplined and if the application size is exceeded, stop the work and look for a solution to reduce the application size. For example, look for a code that is no longer used. Or sometimes some dependencies are no longer used but are still part of the application.

Missing or poor loading and run performance monitoring

Continuously monitoring application performance, quality, and speed is the key to maintaining high quality. One must remember that every slow performance costs time. The time that you then have to spend on analyzing the causes of the slowdown. The sooner this is detected, the greater the chance of spending less time implementing improvements.

Unreadable code

At first glance, this may seem like something of little importance. In fact, unreadable, incomprehensible code impacts the time spent on implementing a solution or fixing a bug. By reading the code, it should be easy to understand the logic behind it. Remember that you write code for humans first, not machines. Your teammates are reading it. Machines don’t care. Machines only interpret it.

How easy it is to understand the code (not its implementation!) determines the performance and quality of software development.

Example of code that takes longer to understand because you need to read the whole code to understand what is the expected output.

let elements = Array.from(document.querySelectorAll('div'));

elements = elements.filter((element) => {
  const elementChildNodes = element.childNodes;
  let result = false;

  for (const elementChildNode of elementChildNodes) {
    if (elementChildNode.nodeType === 3) {
      result = true;
      break;
    }
  }

  return result;
});

Example of code where the execution logic and expected behavior are explained straight from the code itself without looking at implementation details:

const elements = Array.from(document.querySelectorAll('div'));

elements = elements.filter(elementsWithDirectTextDescendant);

Unclear defined requirements

Never be afraid to ask questions. Unclearly defined tasks slow down the entire process of implementing the desired solutions. 3 simple steps that may help:

1. What is the actual behavior or output?
2. What is the expected behavior or output?
3. Do I have everything necessary to get the job done? For example: do we have UI design ready?

Summary

Improving the software development process is always a challenge. It can’t be done within one day. However, the moment we can implement it within 3 months turned into we can implement it within 3 days is the moment you can consider your software development process optimized.