Refactoring Software: An Unconventional Approach

The Ubiquitous Challenge in IT

(🔗 Video)

Almost every IT company I know, including my own, experiences the same issue. You build software, and no matter how hard you try to make it scalable, you end up with software spaghetti that you're not proud of. Some sooner, some later. And then people come in and say you need to rebuild everything because it’s not scalable, you’ll keep encountering more errors, the code isn’t maintainable, and therefore you need to start over.

The Inevitable Refactoring Dilemma

As mentioned, this happens regardless of how good the initial developers were, how much effort was put in, and how many resources were invested. Typically, when you embark on this refactoring journey, you hire new people who understand the new technology and architecture. They come in, redo everything, and you freeze development on the existing technology because something new is coming soon. These new developers take over, the process usually takes much longer than planned, and initially, the new system does much less until you eventually reach the previous level. During this period, nothing noticeable happens for the customer. And if you're lucky, the refactoring even succeeds. Sometimes the whole refactoring project fails, leaving you worse off than before.

The Human Component of Refactoring

Another disadvantage of refactoring is that the people who were previously maintaining the existing technology suddenly find themselves working on the old code and feel undervalued. Their performance drops, as does their motivation and connection to the company. When the refactoring project is finally completed, many of these individuals are burned out, and you lose valuable team members who no longer identify with the new technology.

An Unconventional Approach

I propose a rather unconventional, different approach. First, I suggest that from the beginning, the technology platform should be optimized for development speed. This means doing everything possible to deliver features to customers quickly, trying things out, and if they don't work, discarding them without much regret. No matter how messy it gets, no matter how many rubber bands and patches you have to put in the code to make it run. This is how most successful tech companies started or ended up eventually. So, embrace it and don't fight it.

Continuous Improvement Instead of a Complete Rebuild

When people are hired who say the code is terrible and everything needs to be rebuilt, you say: "I know, but we are where we are because we did it this way. Otherwise, we would have a great technology but no customers. We'd rather have many customers and a suboptimal technology that we can improve." Then, you can come in and refactor all you want, but you do it with a car driving at 200 km/h on the highway. You can change the wheels, but we continue driving at 200 km/h. This means the speed of feature delivery remains high, and we change everything underneath. With what’s possible at this speed and within this speed.

Refactoring software is not a restart but a continuous improvement process carried out in an ongoing operation.

Strategic Personnel Decisions

A very important aspect is that typically, to speed things up, you start by hiring more people into the IT team because you notice it’s getting too slow, the code is falling apart, and therefore you hire more people. This is a very, very wrong strategy. This means when you start hiring the first programmers, you don’t hire average ones, but excellent ones, who may also cost a lot. You start by hiring only one, not many, but one who actually learns to understand the code first. This person can then adjust and change the code but must also commit to working within this code and maintaining the speed. The problem is, if you hire several people right at the beginning, exactly what happens: they tinker on one side and something explodes on the other end. You need excellent developers who work on this platform, continue to deliver features quickly on one side, and carry out refactoring on the other. It is not easy to find such people, but if you hire too many programmers, it will backfire.

Summary: Embrace It!

In summary: Embrace it! Develop at maximum speed and accept compromises in architecture and code quality. As you grow, grow with excellent programmers who maintain this software at high speed and continuously improve the architecture during ongoing operations to take it to the next level. Remember, the people behind the code are as important as the technology itself.

(c) me ^ ChatGPT

#Refactoring #SoftwareDevelopment #Technology #Innovation #TeamMotivation