We had a somewhat similar situation: - Client has complex-ish billing rules that need to change periodically - Their desire was a system that would allow busi

We had a somewhat similar situation: - Client has complex-ish billing rules that need to change periodically - Their desire was a system that would allow business bods to implement new and modified rules without pesky IT involvement - Client was demoed a low code / visual programming tool, and fell in love - We were brought in to team with the company that produced said tool to deliver the system - client's IT department were Java-oriented, but were specifically overridden by the business for this project ! Well, we delivered, but the emergent reality was very different: - It became clear very early on that the tool required specific programming skills and training, and there was zero chance a non-programmer could make any headway - Because of the limits of the tool, the codebase ended up far more intractable and complex than it would have been using a regular language / setup - The tool required regular version uplifts, which necessitated some code changes and other shenanigans, all extra ongoing cost on top of the licence fees - The only people who could do anything with the tool were consultants from the company that made it (and a few of our folks who did training) - vendor lock-in with a vengeance In a bitter irony, for test purposes I wrote a parallel implementation of the billing rules in Ruby, using that language's superb DSL capabilities, and that was a million times clearer and more maintainable. If I had a time machine, I would go back and persuade the client to instead go with a Java solution with Groovy to do the billing rules, as its DSL capabilities are on a par with Ruby's.