We can say that in a business, you always have to focus on things that do not work, and never touch what’s going well … we’re never immune to a mistake of judgment.
In this connected world where 95% of the source code ends up being crushed by new pieces of code, we know that we should not risk breaking what works – and yet … we repeat this error again.
Several factors can lead to re-writing a code despite common sense. Some are commendable, others much less.
1 – The pride of the programmer and the need to control everything
Get a new programmer into your business, and it’s a safe bet that if he’s not directly guided, he’ll want to install his own development environment with his own framework, his own libraries, and so on. This is a logical reaction, because the programmer wants above all to be efficient and feel good with his own tools. But unfortunately, this often leads to letting him prefer to re-write the old code to conform to his own habits. Rather than analyzing the existing code, he might prefer to rewrite it to make sure he stays in control. After all, he becomes responsible for the code he writes, so as far as he knows it perfectly?
2 – An obsolete technology?
Our customers use software programs in languages that are on the way to extinction? Yes, it would indeed be wiser to think about migrating – but if these languages are still maintained? Did you know that Delphi enabled 64-bit and multicore programming? Of course, it becomes more rare to find programmers mastering this technology. You have to think about migrating for the right reasons – programmers often prefer new stuff, so you do not get bogged down in obsolete technologies. It’s a kind of forward race that it’s hard not to participate in.
3 – We think we know better than the customer himself
This is probably the worst reflex. How often can we get an idea and say that the market or the client will adopt it? The computer scientist must first of all be attentive – the client knows his job, he feels his needs – to us to translate them into functionalities that respect his constraints (budget, deadlines and desired quality).
4 – The pursuit of performance
Code can always be improved – it can be made faster, more flexible, clearer, more efficient, shorter, better documented, etc. Perfection is an enemy of productivity. Get the job done!
5 – More budget
Unfortunately, it’s sometimes easier to sell a new code to a customer than to upgrade an old one. Some methodologies, poorly used, can lead a project to never end either, with a pack of paid consultants and successive iterations that never converge to a solution … time passes and managers change, we leave from scratch, and we consume budget. In some large structures, one even wonders if it is not a disease, a kind of continuous development where, from a distance, we know that the code is completely replaced every two or three years.
6 – Moving away from standards
Before you want to write a code, it’s probably better to see if it does not already exist somewhere – can we contribute to an existing open source code? Can we buy a library maintained by a community of developers? Re-writing the wheel is a sure way that one day its code will be replaced by another.
Finally, we come to the conclusion that it is better to stay in the most standard environments, produce the least custom code possible, and most importantly, always listen to the customer’s needs and never attack. to something that works without a great reason.