Let's Rewrite Everything

> Someone is likely to point out all the problems your rewrite will bring. You’ll find it much easier to convince people if you’ve already throught these through, and you bring them to the conversation yourself.

I wish more people did this!

The author seems to be generally pro rewrite in his article so I can't tell if this is sarcasm here.

I have participated in a few (small) rewrites that were successful, and this would be my advice: Don'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're confused about why a project first grows in complexity before shrinking, watch "All the little things" by Sandi Metz, it's the greatest programming talk ever recorded. If your rewrite gets stuck after adding all of that complexity, then you'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've failed to rewrite everything and some chunk of your users are still using the old codebase. Now you've got twice as much code to maintain.

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.

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.

The shocker.

(That said, yes, motivating developers is a thorny problem.)