Refactor vs. Rewrite

In my experience, refactor vs rewrite is the wrong approach. Knowledge of the business must be maintained.<p>If knowledge is on the team because the company is stable, rewrite. 37 signals is a clear example of this.<p>If the knowledge is in the code, because multiple people or teams worked on the code base over the past few years, refactor. A rewrite will be the recipe for disaster.<p>I never found an exception to this rule.

IME whether you rewrite or refactor, the lesson is the same: You have to grind your way into the good architecture. It doesn&#x27;t become good because the code is fresh, but because you have battle scars to show.<p>And a success story in that case comes from having a complete learning loop. In a lot of orgs the learning itself is argued against for one reason or another - development proceeds with as little feedback on quality as can be gotten away with.

So they got off of Elixir and microservices, but their introduction of Typescript and GraphQL didn&#x27;t pay off like they hoped, and now they need to get off GraphQL. I think the lesson of &quot;Choose boring technology&quot; applies here. One of the reasons rewrites are risky is that very often the new tech doesn&#x27;t live up to expectations.

I rewrote a codebase for a major stock exchange in about four months. It was originally in Ruby, which is my most proficient language, and my implementation was in Python, my second most proficient language.<p>The original Ruby codebase had been worked on for years and was a complete mess. Not because of Ruby, but because the people that developed it were a little sloppy or junior or time pressured. Who knows?<p>It&#x27;s totally possible to do a rewrite and to do it well. The advantage of having a pre-existing implementation is that it&#x27;s far, far easier to write tests before you implement because most edge-cases are covered in the existing implementation. Make sure you do a feature freeze before you start, then once you&#x27;re ready for production do both shadow testing and canary testing and things will go well.

I <i>constantly</i> refactor my code, even the ancient stuff. Here&#x27;s my most recent one:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;dlang&#x2F;dmd&#x2F;pull&#x2F;11202" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dlang&#x2F;dmd&#x2F;pull&#x2F;11202</a><p>which changes a data structure from a linked list to an array.

My team inherited a 70%-complete AngularJS application, the user interface for a passengers and crew on a new series of airplanes. It worked fine enough on modern tablets and phones, but there were also some interface devices hardwired into the planes, which would be very challenging to update at this point, and on those devices the software ran very slow.<p>Through several experiments, we determined that the sluggishness was unfortunately coming from AngularJS. We tried some performance improvements, but it wasn&#x27;t getting very far.<p>We built some prototypes using other Javascript frameworks, and found VueJS gave us the best performance.<p>Management was concerned about us rewriting. The end customer was concerned about us rewriting. So risky! But we saw no other way to deliver adequate software performance.<p>We got done on time, with great system performance, to the accolades of a very happy end customer.

When a developer says &quot;I am going to rewrite ...&quot; you have to question why? If you were not doing this &quot;rewrite&quot; then what else would you be doing? Refactor is usually a term used to minimally modify legacy code to allow new functionality to be added.<p>Rewriting implies rewriting legacy code (regressions) and wasting time. If a developer says &quot;it&#x27;s the only way&quot; then you need to be sure you can trust their judgement.

Refactor is a good word to use if you don&#x27;t want to upset the coworker who&#x27;s code you completely replaced.

I found the move away from GraphQL again interesting, maybe because it supports some of my concerns about it. I never looked in detail into GraphQL, but just from the general principles I understand I found it rather scary to decide to use it.<p>It&#x27;s a big complicated thing directly between the data and the frontend. If anything goes wrong there, now I have to debug a much more complex piece of software than if I use a REST API. And just like in the article, based on my superficial knowledge I was concerned that it could be easy to create bad queries, and hard to fix performance issues.<p>I&#x27;m not saying GraphQL is bad, I really don&#x27;t know enough about it. But given the central position it takes, I would not feel comfortable deciding to use it without a serious amount of prototyping and getting to understand how it works. It often feels weird to me that such a complex piece in this kind of critical position is often casually recommended for any kind of web application.

Maybe controversial but I think original authors should be able to rewrite, i.e. they can learn from previous mistakes and incorporate those lessons into the rewrite.

It&#x27;s always a judgment call. But in general, there are a few things that make the choice easy.<p>Any UI project, I tend to look at the expected shelf life of the thing knowing full well that most UI projects get discarded pretty quickly. Stuff like backbone, angular 1, etc. were pretty popular a few years ago and you don&#x27;t hear a lot about people whining about refactoring those. Mostly those code bases have already been changed; several times probably or abandoned.<p>So, if we have a bit of UI and it&#x27;s important for it to be right and it is clearly not and I have a team of developers leaning towards unceremoniously dumping the old code base, I&#x27;m not going to object very long or hard. The reality is that it probably can be fixed but all the people interested in doing that have gone.<p>For backend systems it&#x27;s different. I regularly see code bases with long histories. Often a good sign of how good they are is if people can work on them with confidence. In those cases, I lean towards doing more incremental changes. Update dependencies, modernize a few things even if they&#x27;ve been fine, etc. If that&#x27;s not the case, it&#x27;s a net cost sink and something needs to be done.

A good rewrite looks like a refactor.<p>Strangle that monolith and none will be the wiser.

I think we need to focus on even more basic point while deciding between refactor vs. rewrite. That is whether the basic DB schemas&#x2F;Data Structures are well designed&#x2F;suited to current business understanding or not. Because rest of the structure stands on top of them.<p>I do not see how you can refactor stuff if the majority of the DB schema&#x2F;Data Structures are built incorrectly and&#x2F;or not suited to current understanding&#x2F;layout of the business. You will have to rewrite.<p>The only case where refactor can possibly work is that basic DB schema&#x2F;Data Structures is 90% good and changes are only required at the business logic level.

I feel there&#x27;s room for something in-between (reimplementation? resurrection?): start with a clean slate, and bringing in large swaths of functionality and code and then rebuilding other parts. I think this is useful when you have a lot of work to upgrade an older version of your core framework or many dependencies, you&#x27;re changing a large piece of your infrastructure (like a database), or you have a lot of work to &quot;fix&quot; your test suite.

I think rewriting is a great option, provided both options are weighed up appropriately.<p>However saying this, we made the decision to rewrite a legacy system around a year ago and the project got parked due to &quot;urgent&quot; projects being fed to our team. This was frustrating but we could not account for this external factor when weighing up the options.

I&#x27;m in the middle of a rewrite, but because my employer also wants me to do work on the existing application, I end up doing a lot of refactoring as well - if only for my own sanity and to help me understand the existing code.<p>We&#x27;re talking an only 8 year old (continuously developed during that time) app built in PHP and JS, but by someone who never bothered to learn web development proper. Resulting in a lot of copy &#x2F; pasted code, string concatenation to produce HTML, etc. The problem isn&#x27;t so much that, it&#x27;s that the original developer was also highly productive, so the codebase exploded to nearly 200K LOC.<p>They recognized the existing UI was not going to work, so after the previous developer left, they put out a job advert to which I was recruited for. The job being to rewrite the application with modern technologies, with stuff like structure and tests built in this time.<p>I was okay with that, I mean I could probably do some things with the existing UI but it would be very labor intensive and if it was ever finished, it would still be a mid-2000&#x27;s-looking Dojo app.<p>I&#x27;ve (for now) decided on Go and React, deploying it as a self-contained application (our distribution is via RPM packages on bare metal or virtual servers). Not sure about Go at the moment, most work is straight data manipulation (think REST API, database and writing XML files), struggling a bit with things like data consistency (because Go won&#x27;t enforce you to set all fields, mind you neither does Java but you can have Lombok generate constructors and the like).<p>Anyway, my problem right now is that I was hired under the premise that maintenance of the old app would be like a day a week at most. Of course, in practice they&#x27;re asking me to add new features to the existing application, so I&#x27;ve been spending over half my time on it instead, not making much headway with the rebuild.<p>My fear right now is that they&#x27;ll scrap the new UI in favor of just keeping the old one around. But there was an article a while ago that pointed things like that out, I believe it was titled something like &quot;why rewrites fail&quot;. Very close to home.<p>I mean I still believe a rewrite will be beneficial, but it&#x27;s going to take at least another year and a half I think before it&#x27;s feasible to replace the existing UI.<p>Should have a chat with the boss whether we can hire more people to work on it and &#x2F; or the existing application.

My last 3 clients wanted me to rewrite their React Native apps back to native iOS and Android like in a separate codebase. I’m not sure if this is a trend but their common complaint was that they are sick of the performance of the app and each platfrom has a unique bug. Also this one project written in RN took like a year to develop.

I think everyone is missing the big point here: they current implementation was in an untyped language and so refactoring was just to hard. Use languages with good type systems and then refactoring is easy, and always the correct technical choice.<p>Let me say that again, the killer app of type systems is that no mistake can &quot;total&quot; the code.

This blog post doesn&#x27;t seem to mention how long the process took - that&#x27;s what I&#x27;m most interested in!

Rewriting has a concave payoff. It requires high levels of certainty to be valuable. The bigger the rewrite, the more likely you&#x27;re less certain than you think.<p>Refactoring is the same as rewriting, just on a smaller scale, which increases certainty.<p>Joel&#x27;s advice assumes you will overestimate your certainty.

Some rewrites can be easy because a better technology exists that makes it easy. For example, you might have a NoSQL DB with lots of hand-rolled queries, and then you get a query language for it, so now you can rewrite a great deal of code. You still hand-roll transactions because eventual consistency, CAP, and all that, but then you get a SQL DB that... gives you all of that anyways but with good ole SQL (with eventual consistency, not ACID, but hey, CAP), so now you can rewrite the queries and the transactions, and maybe that&#x27;s the lion&#x27;s share of the app, so you&#x27;ve essentially rewritten the app. What about the REST layer? Well, you get inspired by PostgREST and write a similar tool for your new DB and there&#x27;s nothing left of the original.

I would argue that rewrite is slightly more difficult then refactor. Refactor means, after all, making the current system better while rewrite would mean no update&#x2F;change&#x2F;feature on the current system and more pressure to get it done.<p>I would herby say that a good team with experienced people will succeed in both cases while an less experienced team will probably have a higher chance of doing a refactoring then a rewrite.<p>I like refactorings better. It allows me to optimize a system slow and steady.<p>I like rewriting better if you don&#x27;t need to support the old env while doing the rewrite and having expierence in the old system.

&gt; a handful of engineers focused on machine learning (ML). [...] We leaned into a singular moderator talking to a group of people.<p>I am curious about why an early chat&#x2F;conference company needs so many ML Engineers? What are you using them for?<p>(the Remesh mentioned in the article seems to be <a href="https:&#x2F;&#x2F;remesh.chat&#x2F;" rel="nofollow">https:&#x2F;&#x2F;remesh.chat&#x2F;</a> and not <a href="https:&#x2F;&#x2F;remesh.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;remesh.ai&#x2F;</a>, based on previous articles, the logo and blog domain)

I hear more often things like &quot;oh I don&#x27;t have experience with X, so let&#x27;s not use it&quot;. I mean programming languages are easy, frameworks are hard. Like learning how to use Django (which is pretty easy as far as frameworks go) to me seems harder than using React (assuming I know that already) with TypeScript instead of JavaScript. I would probably be really happy to use TypeScript instead.<p>If Elixir was a really bad match because it was hard to use the required libraries, OK I can understand that.

I don&#x27;t know if this is off-topic or not. More times than I care to admit I&#x27;ve lost hours of coding due to crashing without saving first. Without exception when I redo the lost code it&#x27;s far better designed than the original and usually (not always) in a lot less time. I&#x27;d almost be inclined to recommend always throwing away your first completed effort and rewriting it while your mind&#x27;s fresh.

A really undervalues idea in software development is architecting software for rewriting it in the future. If you make your software small and well defined, then it becomes a reasonable investment to simply rewrite it from scratch.<p>This is a great talk about this idea: <a href="https:&#x2F;&#x2F;vimeo.com&#x2F;108441214" rel="nofollow">https:&#x2F;&#x2F;vimeo.com&#x2F;108441214</a>

Probably it should consider the alignment to the business strategy. Developers tend to rewrite because of tech challenges. But I agree with the conclusion and rewrite should be considered if it is impacting the strategy.

&gt; ... We had very poor test coverage in the areas most in need of refactoring because they were the oldest code, written before we established good test practices.<p>That&#x27;s probably not a coincidence. I like to ask those most strongly opposed to test-first development how they refactor code. I have yet to get an answer the leads to anything other than a rewrite at some point.<p>Of course, the rewrite might be coming for the test-first codebase as well. But in that case, the test suite can be leveraged to great effect as a detailed specifications document. This is one of the benefits of test suites that doesn&#x27;t get enough attention.

AngularJS seems like the number one culprit to cause people to raise their hands and go with the rewrite over refactor approach.

Refactoring&#x2F;Rewrites is the MOST rewarding task that can be achieved with both legacy and new code. I do it from the start of my career (when I don&#x27;t even know the name of it).<p>And that include, regulary, rewriting to different langs (like, for example FoxPro -&gt; C#, C# -&gt; Python -&gt; F# -&gt; Swift (aborted) -&gt; Rust (noob) -&gt; Rust (now I know rust, almost!) &lt;-- yes, the same project, years on it.<p>Exits a lot of FUD against this. Is risky? Is hard? Can be messed up? Everything is staked against you? Yep LIKE ANY OTHER CODE ACTIVITY.<p>----<p>Things that help in make this a success (assuming, of course, an average, half-decent developer. But I have done it when I not even know anything, so who knows if it work?):<p>CRITICAL:<p>- Have source control<p>- Have a task manager (mine: pivotal)<p>- Split stuff in small tasks (couple hours max)<p>- Priorize to know the data(schemas), the business REAL priorities (because all the time, everything will be declared of imperative importance). The code? Less so. If the code is good then you are not considering this at all.<p>- This can be done in the small or in the large. So, a full rewrite can be totally done in hours. If all is so tangled this is not true, then the code is beyond salvation, REWRITE.<p>Nice:<p>- If possible, deployable code in one go (of the old code)<p>- The database (or data in general) is kind of easy to grasp (if not, all is a mess, REWRITE). With a good database, rewrite is far more profitable than refactoring messy logic.<p>- Have good test that can be used to validate it? Great. I rarely have that luxury.<p>To become good:<p>- Rewrite&#x2F;Refactor is a <i>muscle</i>. The more you do it, the better you become.<p>- Do <i>A LOT</i> of MICRO side-projects or experiments. Trash them, rewrite them, explore them. Make your mind used to it (note: this is not &quot;ruin my life, only code yo!&quot;, is to start a major idea with a micro side project before commit bigly)<p>Everyone know the second time your code is better. Imagine if you do 5 rewrite in successions. That code will be celestial!<p>- Be confident in being able to read code. Read code. And read more. Much more if is a new lang.<p>- Ask question, and ask the same question, differently.<p>- Pick a project that you can do in your sleep (mine: Pseudo micro ORMS) and start with that when new lang or framework. In a side project. Must be of small size (few files, at most)<p>- If change lang, framework, be aware that some are BETTER than others. Learn to know why and when start using it.<p>- Dedicate a few minutes learning useful stuff.<p>- Do the HARDEST stuff first, at least, a significant piece of it. If the hard is done, the rest is easier!<p>- Have a solid selection of companion tools that you RARELY need to change (mine: Sqlite, Postgres, nginx, ubuntu (deploy))<p>The MORE messed up, the BIGGER is the payoff:<p>- Not have tests or are all useless? Start writing test and all is tangled? Rewrite<p>- Like a stupid idiot you are 4 months into a refactoring (doing stuff properly and all) and all paths lead to doom? Rewrite (you probably feel it 3 months ago. Idiot me)<p>- You testing (manually, auto, whatever) take X times than write code? Rewrite<p>- The customer is on fire, nothing work, all things are delayed? Rewrite<p>- Everyone in the path of requirements are even more lost than <i>you</i>? Rewrite<p>---<p>Surely exist some stuff that is conveniently ignored in this list: Have a customer&#x2F;team that accept the rewrite.<p>Look, if the customers&#x2F;boss&#x2F;team is THAT bad, then NOT MATTER what you do, you ARE SCREWD.<p>But I&#x27;m lucky, and have worked in situations with serious trouble (but decent humans around, even if can&#x27;t help much and I must figure a lot on my own) have tell me that people are more accepting of rewrites than some could think. Even delayed projects can be tolerated if exist a good flow of improvements.<p>P.D: This is my experience in my sector, and the few I have done in a mid-size startup...

I think Google even has a policy that almost all parts of code in their mono-repo needs to be rewritten (not just refactored) every 2 years or sth like that.