Stop rewriting projects

Start to adapt them

I’ve heard so many times: “I wish I could rewrite this project from scratch”, “if I would write all that code from the beginning I would do everything right”, “we should maintain that, but we all know that want to rewrite whole that code”.

Each time I hear something like that, the feeling of not understanding and perplexity envelopes me. Why that guys try, want or dream about writing all from the scratch? I think that this is a false hope, that leads to false tactics and behaviors in product development

Why this can happen?

The things to restart all over again is pretty normal for humanity as I had time to see that. In films, in poems, in life, there are times when you want to drop everything and start from scratch. Sometimes because of that you can move to a new place, change the surrounding environment, make new friends.

Same for the project. There are situations when you look at your codebase and you understand “that’s all, this is a complete mess”. You just want to start all over again:

• With new approaches that shines in your ideas of the perfect project
• Without old legacy code that you received, when your project was transferred from outsourcing team to internal development, or you, for instance, came to the old rusty project, which still supports, let’s say, 14 API and uses Java 6
• Maybe without several of your colleagues and with couple new one that think exactly like you, so you would not spend any time for code debates, which you can loose. Here everything will be like you want
• With proper management, that will be respectful for your code refactoring and will not load you with a huge amount of features that they didn’t detail yet. And will provide new features with perfect UI/UX
• With orthodox Scrum, or any else development approach you like

I know that feeling. I had such thoughts some time ago. But the truths is that this will never happen.

Let’s say more clear. That can happen. You will have a cool project, with a great team, with proper timings for features and refactoring, with processes and blah-blah-blah. And I had that project, too. And I grateful to destiny for it.

The main point here: when you want to drop everything and change your life, you drop this and find a new one. You can not just tell, for example, your wife while you together “Let’s start all over again”. This will not work. Because you have a legacy codebase of your relationship, which is not erasable. You need to adapt your relationships together. Same with the project. If you tired and want to drop everything, you can drop the project, company, etc, but you can not stop the whole process and say “Guys, we making sh*t, I don’t like that, let’s start over”.

Rewriting vs Adaptation

Let’s be clear our terms and talk about adaptation itself, because <bore>in any case, you will remove at least one symbol and change it with your one, so you will rewrite at least something in the project</bore>. Well, yes. Technically that correct, but you will not rewrite the project itself.

The key to adaptation in the slight changes you will make in the project. You will rewrite the project. But only in your mind, in mind of your team. You will take a course, and will follow it. And this is not just a refactoring of the project. Instead of making one big step “Rewriting all” or 10–20 steps of refactoring, you will make 1K-10K micro-steps. You will make refactoring all the time, but tiny step by tiny step. That calls incremental refactoring.

In addition, you will try to improve existing codebase little by little. Suppose you receive a new request to change UX for the old page, or you need to fix a couple of bugs on it. Take an additional small amount of time and see, maybe there is a big function somewhere in place related to that functionality. Split it on two-four small functions. For instance for Long method smell, you can use Extract method technic. Especially it becomes easier when you have good test base.

You have not? Then start to write tests. Do you need to fix a bug on the old page? Write a test for reproducing this bug and then fix it, so the test will be green. Voila! you have one test. You need to write new functionality. Write it and then some acceptance tests. All right, you have an additional 10–20 tests. Not bad. Little by little, step by step you will have good coverage for the needed page. Next time you will be able to refactor its methods a more convenient way since there is a little backup for you.

You can not write tests, because of tightly coupled UI layer and logic (business, ui, presentation logic, any of logic). Then start with small decoupling. Function by function, small class by small class. Or you can just make small refactorings without good test codebase. I had this experience, and when you do refactoring not just breaking all and construct again, but with nano incremental steps, then you will be fine.

The main point here: you need to stop aiming at rewriting, on global refactoring, on anything like that. Instead, build with your team a plan, consisting of thousands of small improvements, you can make. Take a course, and start refactoring by the smallest steps using the boy-scout rule (take this article into consideration here).

Example of global thing

Not every step seems so small at first sight. Let’s look at the next example. Suppose we have a project which is already working with the usage of Dagger 2. Assume that you want to migrate to Koin (or Kodein) for some reason. Not only you but the whole team wants to do that really bad. So how would you do that? Or this is an exceptional situation in which you can make a global refactoring a stop the process for some time.

Well, no. First of all, we need to see, whether your project is monolith or multi-module system with design, utility, feature and other modules. If your project is monolith then start with splitting it into modules.

Do be afraid of it. You can start with creating utility modules, where you place base, most or all util methods, that helps your team to make a great product. Create a design module and expose some base styles, colors, dimens in it. Create a translation module with all your translations and user-specific strings, text you will show to clients. Those modules (at least their first versions) will not require from your side any hard work since you just moving functions from one place to another.

Then start to implement new features in separate modules. Try place in your feature module as much as you can for the MVP version. There are situations when you can not make a perfect feature module since routing/ui/paging are tightly related to the application module. But you can start with business logic, specific models, interfaces, presentation layer.

When you have some feature or utility modules, let the object of classes within them inject other objects through Koin, not Dagger. The only problem here will be to gather outer dependencies, that are still provided by Dagger and also expose the module’s dependencies to the Dagger’s object graph. To do that you can add adapting modules. Either Dagger module that will provide all dependencies by delegating the call to corresponding Koin functions, or Koin module that will take Dagger related instances and delegate to them.

To migrating old codebase from Dagger to Koin, you can use the aforementioned glue modules and dependency by dependency transfer all of them from Dagger to Koin. Yes, it is not fast, but this is good enough to not blocking the main development process. All you need to count how fast you may and want to do that.

The main point here: almost every big issue, you have, can be split into the smallest steps to be incrementally refactored. Note that there are some exceptions in that situation. For example, the project was written on Xamarin and you want to make two separate projects, written natively for IOS and Android. In this case, you will have to make this sacrifice.

Adopt the code, treat it like a baby

Last thing is that it is not just important to be professional and keep code clean, use boy-scout rule, make incremental refactoring, e.t.c. It is also very important to not wish to rewrite everything. You must understand that, you need to feel like normal when you incrementally refactor something rather than rewriting all. Because if you will write the project from the scratch either in some point of time you will understand that you need to make a refactoring, or someone else will come and declare that your code smells a lot and need to be rewritten. Break this circle, change your mind.

Stop thinking that you want to rewrite all. Adopt and adapt. Or don’t come to the project you don’t want to treat.