This would be better using …
We all experience software products or projects that are years old, written well before we’ve encountered them, and are filled with antiquated and difficult to change code. It’s easy to think about refactoring them with the latest and greatest technologies. It’s very easy to think: “I know, I’ll just rebuild it with X and everything will be better”. But most often that isn’t straightforward.
We’ve always done it this way
The tried and trued pushback for refactoring is the excuse that it’s always been done that old way and switching to a new way doesn’t provide enough benefit or doesn’t account for all of the old lessons learned. On rarer occasions you can encounter architects who take issue with any changes to design, and in the worst cases receive feedback about their original designs as offensive.
We don’t have time
This is by far the most used excuse for refactoring. It’s not always wrong though. If you don’t think through the entire refactoring process, you are likely to under estimate the time it could take. Let alone, you don’t know what you don’t know, and refactoring is a constant state of learning.
There isn’t anyone available to do all that
Refactoring software always includes a learning curve. You will rarely experience teams that are so well tuned that they can take on new languages or technologies quickly. And if we’re being honest, most of the time we don’t have a full expert view of the new tech or language ourselves. So this means there is not only the effort of changing all the code, but also the teaching and learning cycles that are required to do it effectively.
What can we do?
For many of us we need help formulating the arguments for such big and lengthy projects. It’s not enough to just state the obvious, it requires some art and in our sessions we’ll work on communication styles and develop plans that are appealing and worthy of attention. We can break down the problems and iterate piece by piece, and also provide strategies for implementation that assure everyone is on the same page. Refactoring software happens all the time, and we can develop a plan that mitigates friction and provides you with an opportunity to grow and possibly lead.
