Are you for rewriting a project from scratch or refactoring code?

When it comes to tackling new projects, two schools clash with developers: some prefer to exploit an existing code and adapt it to new functionalities, while others prefer to start from scratch although there is a code existing.

Joel Spolsky, an American developer and writer, is part of the first school. For him, writing a program from scratch is the worst strategic mistake a developer can make. In a post, he listed several cases to better understand himself, among others, the Netscape browser which no longer exists today.

Twenty years later, Nicholas Tietz-Sokolsky posted a post on the Remesh engineering blog where he comes to challenge this philosophy, if only through Remesh’s own experience:

“Our story starts in January 2019. Remesh was a much smaller company then. We had recently hired a few engineers and we had 5 engineers focused on the product, and a handful of engineers focused on machine learning (ML) or DevOps. Despite recently hiring these engineers, our velocity was still painfully low. Simple features took a long time to add. We had a lot of bugs in the product that we simply acknowledged as “known” and did not fix. And the product as a whole looked like it had not changed significantly in a while.”

“It’s important to understand why we had those problems. We hypothesized (and after the rewrite, validated) that the problem was not our people: we had hired great engineers. The problems were largely our codebase and our process. The legacy codebase we were working in was ill-suited to both the skillset of our team and to the problems we were solving, and our process encouraged and relied on siloed knowledge: there was no “full-stack” at Remesh.”

The state of the codebase in January 2019

The old Remesh app was originally designed for something very different from what it is currently used for. Initially, Remesh allowed users to hold two-way conversations between entire groups or an individual and a group. Nicholas illustrated the first use case (two-way conversations between groups) by talking about Democrats and Republicans talking to each other to find common ground, the second (two-way conversations between groups and an individual) by talking about the mayor of ” a city that addresses its citizens to better understand their needs.

As a result of this change, some old design decisions no longer made sense, and the diagram required major changes. Beyond the database issues, he acknowledges that the code base itself was quite difficult to understand, as the features had been bolted down without much major refactoring: “We had very poor test coverage in the areas who needed refactoring the most because it was the oldest code, written before establishing good testing practices. ”

Beyond all this, the languages ​​and frameworks used did not work with their team. The backend code base was written in Elixir, which few of their developers knew very well. One of the frontend code bases was written in a very old version of Angular and they had two other frontends that were in React: “few of our engineers were comfortable with one, let alone three. The languages ​​and frameworks used did not suit our team or our problem, which slowed us down a bit. ”

Source : remesh

Related Articles
Leave a Reply

Your email address will not be published.