Just like a salami: go slice by slice!
Switching to a new programming language is usually a difficult decision for a company. It is a painful process, it might be expensive and time-consuming and, if wrong decisions are made, you might come to a deadlock. On the other hand, there might be significant benefits in the medium term, for example, more satisfied developers, quicker and more efficient development projects, a better rate of return.
Technology switch projects are usually initiated by developers, whose work is made more difficult by the old system over time, so they do not like it. It frequently happens that there is no up-to-date documentation to the technology, old documentation needs to be dug out, or the technology is simply not supported any more. This makes it difficult to change a code, and modifications often break something else. It is not effective, and, on the other hand, might be very frustrating for the developers. In these cases mostly the technology switch is the best solution.
Although it might be an attractive solution to re-write a previous application from scratch, my experience shows that this is one of the biggest mistakes you can make. It is incredibly time-consuming to re-write a 5- or 10-year-old system, you might be almost sure that something will break, and the new system will know less. The old application – despite all its faults – is well-tested, has many features and is impossible to be reproduced within a few months.
So, instead of throwing out the whole system, choose a precisely defined feature, and re-write it with the new technology in a way that fits the other elements of the system. Moreover, it helps us to validate the new technology: What are the advantages compared to the previous system? How much quicker will this function be? How much will the quality improve?
If the first function had been successfully re-written, you may start with the next one. Just like cutting a salami, you re-write the system slice by slice. By the end of the project, only a negligible part of the codebase will have the old technology.
It makes sense to start the technology switch with a feature that:
So you will not only start the technology switch, but you will also make an outdated function more user-friendly – which means that you will enhance the value of the product.
Before you start re-writing a function, create an architecture diagram which shows how the system is constructed, what the main components are and which parts are affected by the technology switch. In the next step, check how the other parts of the system will connect to the new technology.
This knowledge is often missing at companies. In most of our previous projects, we were asked to help in connecting the old system to the new technology.
In my next article I will list the aspects that need to be considered when choosing the new technology.
Download our related case study that describes a technology switch project.
He studied to be a lawyer and became a dental technician. Then he realized that due to the incredible advancements in technology, there would be an ever-decreasing demand for human work. Richárd Szabó completed the Green Fox course and has been working as a junior developer for the past one year. He managed to fully realize his plan to start working in his new career before he turns 30.
On March 17 we were happy to co-host the “Tech Up Your Business” webinar together with Green Fox Academy live on Facebook and Zoom. Our renowned speakers from Microsoft, SAS and Emarsys discussed the importance of tech skills for business professionals in various industries, as well as achieving a certain level of familiarity with contemporary technologies to succeed in the business world of today.