This past week has seen a particular theme cropping up on certain social media platforms, which I’ve watched with some amusement. It was all sparked by the announcement made by the South African finance minister, Malusi Gigaba, regarding the proposed increase of the VAT rate from 14% to 15%. While the change still needs to achieve final parliamentary approval, it is expected to come into effect April 1st, 2018. And so, those of us in the IT world have read many comments poking fun at the developers out there who are now inevitably sweating bullets, as they remember how they hard-coded that “1.14” somewhere deep inside the source code.
But let’s take a step back for a moment. What is the issue here? To put it simply, a thing that many assumed would not happen in the foreseeable future, looks very likely to happen in the very, very near future. A simple number, one that is so well known, so embedded in our minds that it is synonymous with “tax”, is about to change. And the issue here is that there is a high probability that many software systems out there have been written by people who allowed this variable to become a constant, first in their minds, and then in their code. They have hard-coded the value for VAT.
It seems like such a simple thing to avoid (and superficially, it is) but the truth of the matter is that most seasoned developers probably have their fair share of tales of tough discussions with clients or project managers, fighting to find the balance between meeting deadlines, and catering for edge case scenarios. Scenarios such as government changing the VAT rate by 1 percent.
The following are 3 phrases that will no doubt be eerily familiar to anyone who has been involved in software development.
Unfortunately, we need to look at this situation a little deeper. The VAT rate itself is of course just the single most visible component of this equation. One equally important variable would be the date at which this new rate came/comes into effect. The one without the other is useless. So, making the VAT rate itself configurable is seldom good enough, when one realises this rate does not operate in a timeless vacuum. Further problem scenarios emerge when we start to dig deeper. The system now needs to be able to take into account questions of precisely when the VAT calculation is performed, in terms of the internal workflows, both system and organisational. For instance, perhaps an order record is created one day, and through normal operational delays (whether expected or unforeseen being irrelevant), it is only populated with line items over the course of the following week. The order is then picked or manufactured (again, over the course of a few days or weeks), and then perhaps consolidated with other orders, and maybe its delivered a month later. Or perhaps it’s a monthly recurring order, or a staggered monthly delivery of services, and so on. How confident are you that your analysis and development teams will apply the correct VAT rate here? Do they know whether to calculate at the point of order placement, settlement, delivery, etc.? Do they know about fair apportionment in the case of recurring or partial deliveries?
Lastly, is the system storing the “right” information about each transaction? Too often, important principles or practices can become harmful if they have been applied a little too eagerly. One example here might be something called normalization in relational databases. While highly valuable for a plethora of reasons, this “decoupling” of information might conceivably (or at least, theoretically) become problematic if it becomes difficult to identify which VAT rate was used on a particular transaction. Note that in the case of a nation-wide, date-specific change like this, much of this can be worked out after the fact without too much concern, but the principle should hopefully still be apparent.
In many businesses the change of a single value, in this case the national VAT rate, is going to have a cascading effect through systems, and over time. Adequately handling this change and future changes like it will require the judicious facilitation and collaboration between multiple areas of expertise - internal business processes, design of internal systems, design of 3rd party interfaced systems, industry expectations, and even tax law, to name a few.
Hopefully, the challenges faced over the next few months are fewer than expected, and easily and quickly resolved. Moreover, this will in future hopefully become an object lesson to product owners, project managers, and software engineers. A team that allows itself the space to build deep insight, foster and apply foresight supported by experience, ask the hard questions, and perhaps most importantly, challenge the easy answers - this is the team that will be indispensable and invaluable. This, coupled with the willingness to learn from similar lessons in IT’s short but colourful history, is the key to confidently navigating the inevitable changes to things that will never change.
Normalization: Wikipedia - Database Normalization
Hard-coding: Wikipedia - Hard Coding
Please contact us by