How to transform a monolith

How many of us have been in situations where we discuss what to do about our precious monoliths? The blobs of code that we no longer dare to touch because we know that it is hard, brings new errors and takes forever to test?

?

I remember some years ago there was a monolith that then was over 30 years old, and the attempts to replace, refactor, replace it and cut it in pieces etc were endless. I would assume it is still there...

?

I have also seen projects where it was actually possible to start disconnecting different parts, removing dependencies and making them autonomous. But the steps were many, involved a lot of people and it meant really treading lightly when doing changes, but successful with time.

?Why do we have monoliths?

The reasons for ending up in these situations can be many; lack of knowledge, lack of priority, lack of interest and/or understanding from managers, lack of time, lack of money. Maintaining a good, useful, easy changeable software takes diligence, strategy, discipline and a common understanding and priority between engineers and managers, product owners etc. ?

Most of all it requires tough decisions.

Choosing the future over the here and now. Choosing to say no to new business opportunities because you understand that it will hurt your code base too much, choosing to push a deadline to make room for investing in an architecture change that does not provide direct business value, only indirect.

?

BorgWarner Akasol is going through a change from being a great startup company with a code base that has grown as fast as the company, to becoming a full fledged member of the professional company BorgWarner. One of the perks of joining a big corporation has been the opportunity to modernize the code base in another way; creating a new, modular structure fit for future and moving the current functionality into it.

?

Now this may seem like a luxury but it is not done swiftly and easily. This approach means developing the current and the new at the same time, while of course scope changes are discussed constantly due to both customers, electronics changes and preparations for the future product features.

So when it comes to modularity and architecture, this is constantly being discussed. We are breaking down our software into a number of independent modules that can be developed and tested separately with the plan to be exchangeable when needed later on. But with possible scope changes, it is a fine balancing act when it comes to planning to make sure we don't have to develop a module in vain, only to have to re-do it right away.

Three choices

So when dealing with monoliths you need to either:

* Do it piece by piece, have a long term plan on how to cut the dependencies and have a good goal picture and stick to it. It requires patience, and belief that you will continue, because this approach risks getting stopped at any moment when something else gets more prioritized. However, if it gets stopped you will still have value from the pieces that are done. It requires constant prioritization and testing as you are developing and refactoring the same code base.

* Scrap what you have, or just stop developing what you have and start from scratch. Learn from your mistakes, re-use what is working and build it better. If you have a low point in sales and not much deliveries planned, this could be a perfect opportunity to actually just start over. You can focus your complete staff on building it up again and it can go comparingly fast. However, it means not selling or delivering for still quite a long time, depending on how big the monolith is.

* Start a project on the side taking the working parts of the old and add people. This will be costly, but it will be fast and it will allow you to both deliver to current customers and build the new at the same time. It requires planning and synchronizing, and also building a separate team on the side. If you don't have time to wait, and need to deliver to customers this is your choice.

How many monoliths are left in the world to kill? And which approach would you choose?