Let's Rewrite Everything
This is madness. There&#x27;s no real advice about rewrites in this article. The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don&#x27;t actually fix the original problem and&#x2F;or bankrupt the company. You can&#x27;t just wave away those realities with &quot;think about the downsides&quot;.<p>I have participated in a few (small) rewrites that were successful, and this would be my advice: Don&#x27;t rewrite an entire project at once. Pick off smaller features first, get a feel for what your new approach will be like before you commit to the big stuff. This will often mean you have to migrate from a monolithic architecture to a services architecture first. This means your project will grow in complexity first. If you&#x27;re confused about why a project first grows in complexity before shrinking, watch &quot;All the little things&quot; by Sandi Metz, it&#x27;s the greatest programming talk ever recorded. If your rewrite gets stuck after adding all of that complexity, then you&#x27;ve played yourself. Worst thing that can happen is you rewrite your entire project, some users or customers start using the new project, but you&#x27;ve failed to rewrite everything and some chunk of your users are still using the old codebase. Now you&#x27;ve got twice as much code to maintain.<p>Before you start a rewrite, consider refactoring and rearchitecting the old codebase, there might be a gem in there that just needs some love and attention.<p>That said there definitely are famous successful rewrites, and I think web application backends are especially suitable for rewrites. Most famous are Twitter and LinkedIn, Twitter going from a relational database backend to a more appropriate fan out message queue based backend allowing them to scale beyond imagination. LinkedIn going from a big rails monolith to super fast node.js microservices reducing their hardware costs a hundred fold if stories are to be believed.