Should you rewrite or refactor your microservices?

A common problem with software is that overtime the quality of the code degrades to a point that it is near impossible to change something without breaking something else. At this point developers motivate for a complete rewrite, and promise better quality code which can be easily maintained. The problem with this is that you need developers which can write maintainable code. With microservices it is more feasable to regularly rewrite entire applications than it is with a monolith. Because of this I've heard developers say "since a microservice is small, we can easily rewrite it, therefore we do not have to be concerned about maintainable clean code. We can't code for the future anyway.". While in some cases it is easier to just rewrite a microservice, there are several problems with this blanket statement which must be considered.

The premise that microservices are small is not necessarily true. A microservice should serve a single purpose and encapsulate what is needed to complete that single purpose. In most cases a single purpose will result in a small amount of code but there are times where a single microservice turns out to be quite large while serving a single purpose.

Just because you are anticipating a rewrite does not mean you should just write a steaming pile which nobody else can read. When it's time to rewrite the service, how is the developer going to know what the original microservice has been doing all along? It's not common practice to document everything anymore but if you do, issues may creep in when somebody forgets to update the documents when requirements change. This means that documentation is not reliable and the dev doing the rewrite has to go through the code anyway. It's not funny when you are that person.

When I worked at a company which had this rewrite mindset, we still did NOT rewrite microservices normally but made changes to existing ones. Why rewrite the entire thing when there are minor changes required? Well, more than likely you won't rewrite unless the original code is so poor or written in a random language that nobody else knows, then you have to rewrite it. A standard practice of clean code saves a lot of time, and since you know the scope of the changes you know where there may be a risk of errors. If you change everything then you could have broken some feature which was working, therefore everything has to be tested extensively. Think about when business asks for a small change, and you reply with "we have to rewrite 3 services to get that right", they will wonder why, and question the quality of your code.

Although system wide changes do not happen often, just one major change is enough to cause major disruption. I have had the experience of arriving at a company which had 0 tests in place, and I had to get them in place. Due to the mindset of "we will just rewrite the microservice" everything was poorly written. Where adding unit tests should be as simple as plugging classes into the tests it came down to heavy refactoring or rewriting of the entire system.

Believing that a microservice should just be rewritten often leads to poor design because you going to rewrite it anyway, right? Most future changes can easily be accommodated for without being a fortune teller by simply following best practices. If you understand good design, you should be able to write your code in a way that allows you to be agile.

Convincing business that you need to rewrite anything can be difficult because of the potential problems you may create and the time required to do it. Good design allows you to easily read and maintain your code, so that you do not have rewrite but rather regularly refactor. Do Agile developers plan or design?

Check out these links for more info:

My design and architecture repo