Refactor or rewrite?
I’ve just migrated this website and feel the need to write about why I don’t like big rewrites. I moved my blog since the platform I used has flaws I could not live with, and had no power to change. So I had to move. But otherwise I am “team refactor”. Here I explain why.
Specification missing
It is very rare that a system has a complete documentation of its feature set. When doing a rewrite you still have to figure out what to implement. Often that is a big part of the job. That also makes it really hard to estimate the size of the rewrite.
Information in the code
Legacy code contains a lot of information. If you don’t know the code well, it is hard to know if it is domain complexity or accidental complexity. If it is domain complexity, the new system will be as hard to understand, but in a new, unfamiliar way.
Stable and making money
New code has a tendency to be more flaky than old code. Not true everywhere. But those of you who hit this site, while I figured out this or that, knows how my 404-page looks. I have also not written any blogs in like forever, while working on the website. An old codebase can be terrible to work in, but it is often running in production and creating value.
Sustainable
When the code is something you own, its condition is in your hands. If hard to change code is always thrown out, we miss a chance to learn. And it is wasteful. Imagine moving house instead of spring cleaning. The skills we need for refactoring will make our software better in a way no rewrite ever will.
So learn how to take care of your code. Mend it and refactor it. Use patterns that will make it possible to replace parts when they get outdated, without tearing out all the domain code. The grass is not always greener in green field development.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about quality and testing, to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.