Don’t rewrite your project in Rust, or at all.

Šimon Tóth
ITNEXT
Published in
4 min readSep 10, 2021

--

Don’t throw out your main asset.

The decision to rewrite a project from scratch is exceptionally high-stakes and making the wrong choice can end your career and/or company. Yet, our monkey brains love to lean on our cognitive biases and make the wrong choice exceedingly easy.

Let’s have a look at some of the reasons why you shouldn’t rewrite your project.

It will take a lot longer than you think.

Underestimating the complexity and time required to finish a project isn’t anything new in software engineering. But we can make some rough estimations.

Let’s look at the size of the codebase and the number of lines written per day by a developer. Let’s say we have a medium-sized project with 500 KLOC (for scale, Firefox has 23 MLOC), and we have highly proficient developers that write 200 lines of code per day. Let’s also assume that the rewrite will allow us to remove 30% of the code. With 22 workdays per month, we are at (500000*0.7) / (200*22) = 79 people months. That is 6.5 years for a single developer as a very conservative lower bound estimate.

If you believe that you can reduce your codebase by much more than 30%, check the “When to rewrite your codebase?” section.

The grass isn’t greener over there.

One of the common reasons for a rewrite is frustration with the limitation of current tools. However, when shopping for new options, especially when they are relatively new, do take care with the following phenomenons that might be warping your perception.

Reporting bias: People love to talk about their successes, even if they need to invent a success. Similarly, people hate to talk about their failures or even admit them.

Early adopters are extremely likely to report a positive result, despite the reality and not report on the downsides.

Honeymoon period: New things are exciting, especially if you have been working on the same project for many years. However, you need to stop looking through the pink glasses if you want to appreciate any tool's limitations properly.

Early reports will be skewed by the sheer exitement of doing something fresh and new.

Snake oil: Be wary of the person that is trying to sell you on this idea. Do they have something to gain from you switching over? It doesn’t have to be just money.

Does the person that is trying to convince you to switch have a stake in the game? Increase your scepticism ten-fold.

You are levelling the playing field for your competition.

Ok, so you still want to rewrite your project. What about your competition? What will they do while your team works on the rewrite and does not deliver new features for your customers?

You can be sure that your competition will keep delivering features and steal your customers.

Refactor, refactor, refactor…

Instead of a rewrite, one of the main approaches you should consider is refactoring.

Refactoring seems to have a bad reputation with some managers. On the surface, it might seem that refactoring does not add any value to the product, so why do it?

  • Refactoring improves the readability of code, speeding up any future feature development.
  • Refactoring is safe. Each refactoring step will take you from a fully working state (all unit tests pass) to a fully working state. Thus, you will immediately know if you make a mistake and can easily roll back to the previous version.
  • Refactoring is a great way to learn a codebase. In particular, it is an excellent approach to regain expertise in obscure parts of your codebase.
  • Refactoring is narrow in scope. While a single refactoring step might affect many files and lines of code, the scope of the refactoring is always narrow. As a result, refactoring changes are easy to review and to reason about.

Modularise your codebase first.

In a modular codebase, rewrites are rare. Instead, you might replace one of the components, which dramatically reduces the scope and risk. In service-based architectures, you can even write different components using different languages and get the best benefits of using the right tool for the right task.

When to rewrite your codebase?

So, hopefully, at this point, I have made some convincing points about the foolishness of doing a rewrite. But, there certainly are times when you should do a rewrite. Note that having a modular codebase will still help significantly.

No longer fit for purpose: If you are in a fast-moving area, you might find yourself shifting the purpose of your product until the original design of your product no longer matches the needs of your customers.

Do you need to redesign your product? You might also need to rewrite it.

Outsourcing your code: Can you replace your hard to maintain components by 3rd party libraries or services? If your rewrite effectively removes the majority of code from your codebase, it is worth considering. However, do remember that your competition can also use the same libraries and services.

Can you replace a big chunk of your codebase with an external service or library while maintaining your competitive edge? Consider a rewrite.

Conclusion

Doing a rewrite of a project is almost always wrong. We don’t have to go far from the title to see an example, with Firefox quickly losing its userbase.

But at the same time, there are good ways and reasons to do rewrites. I want to leave you with the core idea that a rewrite is a very drastic step, and you should try less drastic approaches first.

And maybe invest in code quality a bit more through refactoring.

Thank you for reading

Thank you for reading this article. Did you enjoy it?

I also publish videos on YouTube youtube.com/c/simontoth and if you want to chat, hit me up on Twitter @SimonToth83 or LinkedIn linkedin.com/in/simontoth.

--

--

I'm an ex-Software Engineer and ex-Researcher focusing on providing free educational content.