Don’t jail your logic in code
Our friends at Data Decisioning forwarded an article from The Register recently – Inflexible prison software says inmates due for release should be kept locked up behind bars.
The basic building blocks of this story is that there is a module calculating release dates for prisoners that was clearly implemented exactly the same way the rest of the system was coded.
This is what we would call a “worst practice” because decisions are not the same as the rest of your system and should be implemented differently. Deciding things about customers, about transactions or, in this case, about prisoners is not the same as workflow or data management. Decision-making should be implemented as stateless, side-effect-free decision services using decisioning technology (decision models, business rules). Not code.
Why? Well decisions are different.
- They are rich in business understanding (in this example, legal understanding).
- They are prone to regular change (in this case because the political and social environment is changing).
- And they are often required to be transparent (in this case to demonstrate that all the correct laws and regulations have been followed).
Code is impossible for business experts to verify, time consuming and expensive to change, and opaque. So writing code to implement decisions is a terrible idea. It’s like taking your business know-how and locking it in jail!
Back to our example. In this case the code of this module “hasn’t been able to adapt” to new regulations even though it has been nearly 2 years! And regulations are generally signaled well in advance so they’ve really had more than two years. If they had recognized that decision-making should be implemented using decisioning technology, this would have been easy to fix.
The most revealing part of the story is the attitude of those who wrote the software. They dispute the use of the term “bug” to describe the system’s “lack of adaptability”. I guess being hard to change is a “feature”? This of course is nonsense. No-one is writing code for a completely rigid, defined, unchanging world. Lacking necessary adaptability is therefore definitely a bug.
What’s worse is that they knew all along that they would have to make changes! They say
It is not uncommon for new legislation to dictate changes to software systems. This translates to a change request and not a bug in the system.
No, wrong. It’s not a change request, its normal operations. New regulations are normal. Therefore change to regulatory rules is normal. Therefore being able to change the rules is normal too, and not a change request. The idea that this kind of change might require 2,000 hours of programming is nonsense. Leaving aside the apparently outrageous rates, this is terrible design and shows either a total disregard for their customer or a total lack of awareness of best practices (or perhaps both).
What this company did was take business domain know-how, business logic, and lock it away in opaque, hard to change, hard to manage code. And then when the inevitable happened and the rules changed, they failed their customer who now has to add workarounds and fixes outside the system – I can see the yellow stickies all over the terminals in my mind’s eye….
So, don’t be like those bozos. Identify the decisions in your systems. Model them so you understand them. And then implement them in a Business Rules Management System so your business partners can make their own changes when the regulations change, the market changes, customer change, their business changes or the world changes. Because it will.
Keep your logic out of code jail.
