Keep in mind: these are all real expressions, captured just moments after the event described. In this case, two competing implementations of functionality were produced to handle two distinct and only accidentally related business cases. The original goal was for the more flexible set, which mirrors other configuration in the system and can be deployed in real-time, to become the standard and for a basic set implemented in compiled Java classes to be replaced. Once the pair had run concurrently in production for long enough, it would clear the need for the second business case, so it didn’t matter that it wasn’t flexible. However, I was shocked to discover developers pursuing customer on-boarding automation had replaced all the carefully constructed logic in the flexible configuration files — with hard links to the java classes!
Through the benefit of hindsight and about 3 fingers of Albany Distilling Company’s Coal Yard Rye, I realized why this had happened: the java configuration, by virtue of a simple set of static requirements, had a really straightforward API and beautiful, self documenting implementations. The flexible configuration, which reused a complex, non-intuitive DSL and implementation from an earlier project, looked a mess. And while the automaton didn’t care about the legibility of its output, the clean and concise java classes had much higher appeal to its developer.
It’s flattering, really. When it isn’t maddening. And hey, maybe we’ll buy back those six weeks with the tool!