As we all already know, or we have heard something about it, from January 1, 2023 Croatia is joining euro area, the Croatian kuna goes into oblivion and the famous euro comes to us as a 'new' means of payment. And now it may not sound like something big since, frankly, a lot of us have been using the euro for a long time in various conversions, payments and other financial combinations, so the introduction of the euro was probably only a matter of time.
Many of us are already calculating and recalculating how much their 'new' salary will be, dual display of prices in stores is already mandatory in order to get used to what is coming, and just like a large number of other developers working in financial institutions, I've also been working on the conversion for months and struggling with processing, displaying and other things that until now were part of the 'world of kuna'.
One of those struggles, so to speak, is hardcoding, so I will base this short text on what it means to hardcode something and how good or bad it is when a project like this comes up, a project that requires going through the entire database and switching everything from one operation mode to another, in our case from kuna to euro.
Let's just take one example from the sea of programs in one bank where a bunch of codes were written just to finish something faster, in such a way that '191' is set for the kuna currency as a value and not as a parameter. The programs for overdue interest in their modules have this value, for accrued interest have its own, for various account inquiries its own, etc., and now we have come to the point that all should be changed to euro, i.e., '978' and, what is even more important, when after changing everything, you need to check its functionality, you need to go through a huge amount of code that requires to be corrected and adapted to the new 'EUR' system.
For example, if we take one module, let it be a package in which we need to set the currency '191' in various places in different queries or controls in the code itself:
And now we have way too many such modules on different instances with different users, meaning that we have to change, control, test and check it in a large number of places. If everything had been set as a parameter at the start, the change would be necessary only in one place, namely in the parameter table.
We have a code table with all important fields, in our case for a bank, so we will have a table called BANK, and the fields inside the table are sort code, pin, and one of the fields also important for this story, domestic currency:
bank. domestic_currency : = ' 191 ' ;
Let's put together a function that will return that field to us, e.g., return_domestic_cur. In that case in our module where we had the currency '191' in n places, we simply define the global variable g_domestic and fill it with our function, so each change of the domestic currency is then controlled by changing the field in the parameter table, and not, as is the case now, by going through each module and manually changing and correcting everything in n number of places.
As we could see from this one short example, conversion to EUR in the developer world can be quite simple and very complex and complicated at the same time. On the one hand, the solution itself is essentially quite simple, and on the other hand, it is complicated because the same solution now needs to be integrated into a large number of modules.
Since I have learned in my long career many things the 'hard' way (you do something one way and then later you have more work to correct it than you would have if you had done it right at the start) I will take the opportunity to state, as a reminder to myself and everyone engaged in this work, that in situations like this we should use parameterization and parameter tables wherever possible and as much as possible.
In the end, I would just like to say that I hope that you could get an impression of the size of this project from this small example, because dehardcoding is only a part of a much bigger story called the introduction of the euro (imagining and writing all the scenarios, creating new modules, a lot of testing, etc.) and that from a developer's perspective I sincerely believe that the whole story will be completed on time and with success.
The project was co-financed by the European Union from the European Regional Development Fund. The content of the site is the sole responsibility of Serengeti ltd.
Get a Quote
To get an accurate quote, please provide as many details as possible. One of our key account managers will contact you back with a custom quote for your project.
Manage Cookie Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.