Refactoring: What Is It and When Do I Need it?

As a regular reader of JetRuby Agency blog, you may well have seen the Refactoring section.

Whilst all of these articles make perfect sense to developers (trust us), it may seem to be of little use to business owners. We’ve created a short introductory article, to answer some of the questions you may have.

So, without any further ado, let’s get straight to it.

Question 1. What is refactoring?

The question is answered partially by the Wikipedia article on the subject:

Code refactoring is the process of restructuring existing computer code — changing the factoring — without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity; these can improve source-code maintainability and create a more expressive internal architecture or object model to improve extensibility.

We’ll try to skip the “boring” techie stuff this time and focus on what businesses actually need.

In more down-to-earth language, refactoring is the process of reorganizing the code base without introducing any new functionality.

WHAT? Basically you want to do something with the code (which I don’t see) and spend precious development time WITHOUT adding new features? You’ve got to be kidding, right?

We will answer this very question a bit later. Thanks for not switching the channel.

Question 2. How do I know if my application needs refactoring?

There are 3 major reasons to perform a refactoring:

1. Code architecture is poor. This happens when the application is delivered in as-fast-as-it-gets manner and the developer(s) and the product owner do not care about the integrity and maintainability of the solution. The situation may get even worse, if the scope of the project has switched heavily, or there were dozens of freelancers, who had been working on the solution at different times (no conventions, no code style, e.t.c.)
2. The project didn’t leave proof-of-concept status in time. It’s not a secret, that some projects succeed, some fail. Smart product owners need to make sure that “killer features” do work as intended, and can be demonstrated to investors and stakeholders. Or, as product companies do, they validate their ideas with narrow focus groups. In each case they assign limited resources to check whether the idea or approach actually works in the real world. As soon as you get a “yes” to this question (it does work), you should budget for the following jobs and (this is an important piece) actually plan or adjust solution architecture. Otherwise you may end up building a skyscraper on quicksand.
3. Technology stack is outdated. This happens too. Technologies evolve rapidly, businesses need cross-platform solutions, mobile adaptation, etc. Take a website from 1999 and try to add some fancy ReactJS interactivity to it. You may try to make it work, but basically the amount of time spent can not be justified by the expected result.

When this news arrives from the development company, it’s cause for tears, right?

Well, yes and no.

You could ignore the information, skip the third-party code audit and just proceed with the current approach.

Here’s list of the possible issues you could run into:

1. The application gets buggy. As time goes, some bugs are solved just to be replaced by new ones. Why? Because developers are fixing issues, but it becomes visible only afterwards that the developers have broken something else. The bigger the application, the more code lines it has , the more intersections there are, the more non-conventional solutions are present — the worse the situation usually is.
2. The application is slow. As you introduce new functionality, you inevitably add code. As you add more data to DB, you inevitably add to the size. So, in the early stages, problems with server-side or client-side performance may not be evident. But as time goes on, they may become pretty obvious.
3. Development takes too long even for simple features. This is related to the previous point. To deliver a stable product, the developer needs to address the issues outside of his scope, basically he does refactoring while at the same time delivering the feature. This works, but lacks a systematic approach. And it isn’t exactly transparent to you as the person paying the bills, right?
4. Some features will not be completed. Again, related to both of the above. Introducing a new component or feature may just not be worth the effort. Imagine you get an estimate and it says that it will take 2 full days just to make a simple dropdown menu. The development company would typically just say “you don’t need it”, or something like that. We at JetRuby are not used to saying “no” to clients, but an informed decision leading to zero result hardly sweetens the pill.

Question 3. What is the expected result?

The benefits of a proper refactoring are directly related to the issues we intend to solve:

1. Easier expansion of the system? Better collaboration of developers? Less time on discussions, more time on good solutions. Money saved — [check-icon].
2. Easier implementation of changes? Less bugs? Less QA? Money saved — [check-icon].
3. Better performance of the application on client side? Happier clients — [check-icon].
4. Better performance of the server side? Cheaper AWS plan — [check-icon].
5. Less money spent on support and development in future. [check-icon].
6. The list goes on, actually…

Basically, you will be able to solve most, if not all, of the aforementioned problems.

Question 4. How much does it cost?

The short answer — it depends.

The longer version is… anywhere between ~100 hours and 2000+.

Small projects may take 50–150 hours to update the technology stack.

Bigger projects with changes on the backend and the frontend may easily take 500h+.

Or it may take 10–15 hours, just because we need to get rid of the non-optimal solutions and move on, evolve and fundraise.

It’s important to properly inform the developer(s) with your plans — close and distant. This is a major question from day one. Sometimes (quite often), it makes sense to combine refactoring and implementing new features, when you are sure that older functionality will be changed soon.

When in doubt, you may order a third-party code audit of a proven company. These don’t come cheap, but they may be perfectly justified, when we are talking about 1000+h scopes.

Question 5. How do I avoid refactoring? I don’t want to slip on this banana.

Rule 1. Find the right guys. Development company should be professional, transparent, and with a good reputation. You know one, right? ;)

Rule 2. Be clear with your wishes. It may be challenging to comprehend one’s dream in it’s full glory and put it into SRS. Read how SCRUM works and what a product owner does.

Rule 3. Be specific about your target audience, stakeholders, future plans. The bigger the picture we share, the less room for false assumptions and the higher the chance to meet expectations.

Rule 4. Inform your development company when there’s a major switch in roles on the project, high probability of approach change or scope being cancelled. Remember, we run the project and it should perfectly match the product; you are the person that knows it best.

Rule 5. Do not postpone Quality Assurance to “when the time comes”. Accumulated issues are harder to fix. Also, they will take time (and money) to be solved and you basically won’t be getting new functionality at this point. You end up paying for what you considered to be solved already. You get frustration, and your audience has a gap in releases (assuming they are OK with a buggy app in the first place).

Rule 6. Plan ahead. You will be needing mobile adaptation at some point (very likely). Maybe you will be needing a mobile app? Or several apps and user roles. Try to imagine how it looks in the end, then transfer your vision to the right guys. This enables for effective architecture planning and choosing the proper tech stack.

The Bottom Line

OK, you’ve got the news. Refactoring is needed.

Bad part: New investment needed, sometimes (often) unplanned.

Good part: The product will become better, in so many ways. We hope you can see it now.

Piece of advice — don’t treat this as an expense. This is a smart investment. Deciding otherwise, you may end up spending twice as much later or worse, hitting a dead end.

We intend to publish more articles “translating” what software development firms do into something more to the ground, allowing for better transparency and more productive collaboration.

Please give us a couple dozen “claps” if you feel this article has been helpful.