When you should not rewrite your project

Ruby is great. Python is also great. C# and java are obviously great too.
Even PHP can be great.

So why so many companies struggles with projects written in those languages?
And more importantly: Why they think they need to change the technology and spend a lot of money rewriting their application from scratch.

In this blogpost I will try to help you understand when you should consider rewriting your application to different technology, and when you should focus on finding proper team to repair your current app.

Table of contents

• Who and why suggests a rewrite?
• Most common problems that lead to considering a rewrite
• Differentiating between problems that are connected to the chosen technology and those that are connected to the design of the application

Why and when people want to rewrite?

• We see that adding new features is problematic and takes more time than expected
• Changes or new features cause regressions more often 1
• System is slower than it should be
• Clients frequently reports issues and errors with the app
• Outside audit identified some problems with the app and informed us about "technical debt"
• Someone told us a story about their/other app that is written in another technology and is free of problems that bother us
• Our software provider claims that they do not have enough resources for certain tasks
• Someone from out team is interested in a new technology, they begin to convince us that it this new snake oil is perfect and will cure all ailments

Is that problem related to technology or our code quality?

We see that adding new features is problematic and takes more time than expected

Assuring that the application is sustainable and continuously developed is one of the most complex aspects of designing the architecture of the application and the process of creating it.

The number of errors that can be made during the development of the application increases with its complexity. Not only the number of errors themselves, but also the scope of the areas they may concern.

Badly designed database structure or the way of storing data, chaotic process of designing functionalities, their implementation and testing, or poorly written automatic tests, are just a part of the potential sources of the problem.

However, from my experience, it is most often these problems that cause the situation mentioned above. Therefore, if we identify such problems in our application, we should first analyze which good programming practices are missing - because without them, changing technologies will ultimately lead to the same situation - only in an application written in a different language.

Changes or new features cause regressions more often

Every language, or every framework has at least one set of tools for writing automatic tests aimed at catching regressions even before they are released to production. What's more - they also have tools designed to verify the quality of these tests.

Automatic tests without proper documentation and manual tests will never give us 100% certainty of the absence of regressions, but in combination with the mentioned tools, they will help us minimize their number to an acceptable minimum.

So again - in this case, it is not a change of technology that will provide us with a solution to the problem, but the use of appropriate tools in the way they were designed.

In other words: We cannot rely on an untested and undocumented application, regardless of the language in which it was written.

System is slower than it should be

Probably the most interesting problem from a technical point of view, because it touches many layers of the application and not every optimization is worth its price.

We can use the example of the rage.rb framework vs Ruby on Rails.

Rage.rb in benchmarks of handling one simple request is about 20x faster.

However, this does not mean that an application written using rage.rb will be 20x faster. Especially because the vast majority of time to display a page is not handling the request, but e.g. handling a query to the database, or generating an HTML view.
If processing requests takes 0.2s, and communication with the database 2 seconds, then speeding up the processing of the request to 0.01s will not fundamentally change the user experience.

Another example of simple problems in the code that can be solved without changing the technology can be:

1. unnecessary n+1 queries generating a very large load in the application-database communication. These problems can be easily identified by tools or an experienced programmer (with the help of those tools)
2. excessive number of nested partials whose task is to increase the transparency of the code at the expense of its speed (nested partials vs inline is often a 10x difference in the speed of generating the appropriate HTML)
3. fetching too much data instead of only the data we need in a given view
4. lack of pagination
5. complex operations on inadequate data structures
6. using inappropriate search and iteration methods

As long as we are not sure which part of the technology is a performance problem, and whether we cannot fix it within the technology we are using, we should not think about changing it, but about a thorough audit.

There are, of course, situations where it turns out that the problem is the chosen language, not the database layer or rendering the view. These are, however, usually extreme situations, concerning a specific part of the application that requires a completely different scaling than the rest of the system. For such problems, easily scalable microservices were invented, which in their simplicity allow you to rewrite only the selected part of the system in a technology that suits its needs.

Clients frequently reports issues and errors with the app

No one ever wrote a perfect piece of software. Programmers are still people, people make mistakes. With complex systems, none can really predict all possible scenarios that will happen in production, specially in apps used by hundreds, thousands of people.

However, if the number of errors reported by users is high, excuses need to stop and we need to take a closer look at the quality of the code being delivered to use (from a client perspective). If one new big features ships with only one bug, that is quickly discovered and fixed, we can be happy. But if over the course of weeks or months, the same feature keeps having newer and newer bugs, it is a sign that the code quality is not good enough.

Programmers are not perfect, they often take pride in their work and have a hard time accepting their mistakes. The good ones will stand up to the task, fix their bugs and be happy about making their (or someone else) code better, the app more stable. One of the signs or a programmer with a worse attitude, often is blaming everything and everyone else. Saying that the problem is with the technology or language, instead of focusing on how to fix/bypass the problem is not a productive attitude.

Software developers need a very analytic, often scientific approach to solving problems. Forming hypothesis about causes of errors first before simply spouting "it broke cause PHP/JAVA/RUBY is a terrible language!" is a crucial part of debugging that leads to reducing the number of possible errors.

Outside audit identified some problems with the app and informed us about "technical debt"

Technical debt is a scary term. None wants to be indebted in any way, specially in an app that is supposed to generate them a profit. However, what really is technical debt?

More often than not, it is a problem, that occurs simply with the passage of time, when our application is not being actively worked on by developers. Programmers usually prefer to work with top-of-the-line technologies, newest versions of everything. If we have an app that has this kind of team, we probably don't have to worry about technical debt, but we will have to accept that from time to time, developers will put some work hours into maintaining our system at the newest versions of technologies used.

However if we do not have that kind of team, or no team at all, cause we have a small app that steadily, but surely generates some profit, we will eventually gather some debt.

This is by no means matter of technology. Not a problem of it. It is its nature.

All languages mentioned so far in this article are very active, have big communities. There are many people responsible for developing those languages further. Improving them, fixing bugs, adding new features, changing existing ones. If we use that language, it is best if we stay up to date with those new versions, but that can't be done with the flick of the wrist.

Same with some libraries and extensions, plugins. When we choose a library to be used in our app, we take care of making sure it is still being maintained. If it is, it means that if some problems arise, someone will probably fix it. That means we also need to take care of updating those libs to newer versions. This can sometimes be automated. But often those updates of libs and languages, require changes to the code. Rarely major changes, just adjustments.

Do not get scared by technical debt. Software does not become fatigued, hardware does, human body does, but code does not. However we still need to take care of it, just like we take care of hardware that we run our software on, or bodies we use to write the code. Cause some of us, are just code machines in human bodies.

Someone told us a story about their/other app that is written in another technology and is free of problems that bother us

It is easy to get swayed by success of others, but always remember, that the grass is always greener on the other side.

Other apps, often might make better use of a different technology, while your app might be better suited for the technology you are using.

There is no silver bullet in programming. There are just programmers that have preferences and are better at certain languages or technologies. You do not need a specific language (most likely) for your system or app. You need a specific (good) programmer.

Our software provider claims that they do not have enough resources for certain tasks

This used to be a problem, but now it rarely is. Few years back, before the downtime and recession we see currently in the software job market, clients had problems finding programmers for popular languages like Ruby. This caused some people to misinterpret the situation and think that none codes in those technologies anymore.

The situation was actually the other way around, cause there was a demand high enough, to leave very few free programmers in the market, at least for a longer period of time.

Someone from our team is interested in a new technology, they begin to convince us that it this new snake oil is perfect and will cure all ailments

This is also known as over-engineering or hype-driven developemnt. It is a common problem in software development. It is often caused by programmers that are not experienced enough, not confident in their skills or ones that are bored. They often try to overcompensate, convince themselves of being better than they are or entertain themselves, by using the newest, most advanced technologies, that are often not needed or suited to the needs of the problems they have to solve.

The most common example of this, was the influx of new apps made with microservice architecture. It is a great way of solving some problems, but it is not a silver bullet. It is not a solution to all problems. It is a solution to some problems, usually those of very big and complex apps, that are rarely present in small and medium system.

Not only programmers cause this though. Clients or business people in general, look at facebook, netflix, google or any big successfully company, hear that they use technology X and Y and they simply go "their success is due to this technology".

It is the other way around.

Because someone gets successful, they need to come up with a new technology, or a very complex solution to a big problem (like a huge number of users, or very complex business logic).

There is a great design principle with the acronym of KISS. It originates from the US Navy, but has been adapted by software engineers and it is one of the most important principles in programming in my opinion.

It is similar to Occam's Razor approach to problem solving, cause KISS stands for Keep It Simple Stupid. You start from the ground up, making the simplest solutions to solve problems, and build upon that, instead of creating a complex solution for a initially simple problem.

Summary

Moving problems of application written in technology X into technology Y, gives you nothing more than another cost.
Make sure that your team / contractor is able to identify problems and fix them one by one.
Or if someone is strongly suggesting you to rewrite your app - consider what is the exact profit of new technology and is it worth the cost, instead of removing currently identified problems.