This post has been originally published in a blog I tend to forget I have and I first thought of writing it after a frustrating day at work...
Imagine a system with a scalable and extensible solution, as long as it keeps following the rules according to which it was designed, what actually goes quite against what these two properties advocate. So, whenever someone decides to change the rules of the game, it's no longer able to provide an adequate response. Imagine a system developed using open source and proprietary technology as well. Imagine that the support for the proprietary SW is no longer available as it is deprecated and extremely old. Imagine as well that there isn't any stable version of the source code or executable file, for that matter; if anything serious happens with the proprietary component, the probability of not being able to restore it to a functional state is quite higher than it should be. Imagine that the servers in which the services are running are obsolete but, because of the proprietary component, they can't be upgraded. Imagine that from time to time the need for new developments arises, due to legal requirements and, every time that happens, the developments occur over the existing solution, although only regarding the non-proprietary part of it (yes there's a huge red line over the proprietary part!), even knowing there will be an impact in terms of technical debt.
Imagine that right next to you, there is a solution able to accommodate the existing service and its business logic, allowing simultaneously to scale, extend, change or adapt the rules, whenever's necessary. Imagine that the technical debt could be kept to a minimum or even to dissipate completely (one can always dream!). Imagine that it's also a proprietary solution but a way more flexible one; with support and still having new versions being made available on a regular basis and enable integration with custom developed modules, using open source, whenever necessary. Imagine that it runs on almost any server. Do you know any developer that wouldn't choose this approach if given the choice? I know I would but unfortunately that's not what happens in reality. Either because there is no budget available or because the stakeholders with real decision power, can't fully understand or we aren't able to prove that a minor short-term impact can end up becoming a quite bigger one in the medium or long term. Either because the decisors don't have the necessary technical knowledge that would allow them to make an informed decision or either due to a lack of political will, plain and simple.
How can one overcome such hurdles? Patience and quantification are two possible keywords. Show how much your system costs you currently (hours you spent fixing issues, processing, applying workarounds, etc). Prove how the long term costs of adopting a new solution compensate against opting for developing based on the existing one. Show how a new solution will allow becoming the process more agile, fast, efficient and less error-prone. Prove that using the programming language or framework A is better than B. Show that the support team interventions will decrease. Involve your system end-users if possible; they know their pains and the system's better than anyone else because they struggle with them on a daily basis. They are the living proof of the existing problems and potential bearers of the solution. They can be an invaluable ally.
Be patient. Be persistent.
Please, feel free to share your thoughts and experiences in the comments!
Top comments (0)