OddThinking

Here is a software analysis anti-pattern I have seen many times in my career. It is popping up in my current project, and I am trying to work out how to subvert it early.

Let me describe the cycle.

1. Some set of commonly-changing business rules are hard-coded in the source-code.
2. Developers are too busy or their processes are too slow to be responsive to requests to change the business rules.
3. It gets decided that the rules should be exposed through a user-interface, to allow the configuration to be customised by a non-developer who directly understands the business.
4. Great effort is made to create an interface to support customisation.
5. Optionally: Once again, it is realised that Boolean logic is clumsy in a user-interface that isn’t plain text.
6. Optionally: Some potential customisations are missed, and the interface needs to be redeveloped, or special hard-coded rules are detected in the source and treated specially.
7. It turns out that, although the new interface enables the editing of the rules, it the editing isn’t the hard part. Reasoning about how all the different rules interact – that is the hard part. Considering every situation, not just the main ones – that is the hard part. Testing your understanding to make sure it is correctly implemented – that is the hard part. These are the special skills that the developers bring.
8. The non-developer gives up in disgust, generally blaming the user interface as too complex, not realising it is the problem domain is more complex than they know how to realise.
9. The task reverts back to the busy developers, who continue to laboriously work through the consequence of every change, but now they have to edit the rules in a custom language/interface, without comments, without source-control, without a testing framework, without IDE support, without a coding standard, …