Business People should not Control Code
June 12, 2007
Posted by on
Scott Bellware recently ranted about how there seems to be no end to the number of vendors promising the Holy Grail that allows Business people to take responsibility for changes to their business processes and move them into production code.
Creating software isn’t hard. Making changes to it is hard. And making changes to software inevitably means verifying that those changes actually work, and that the changes to one part of the system hasn’t caused another part of the system to behave unpredictably.
I couldn’t agree more. I mentioned this very point in my discussion around Business Rules Engines.
Recently I was discussing the failure of a past project which relied very heavily on a BRE and one of their biggest pain points was maintaining it. The Business Analysts were not trained to write test cases for their business rules and routinely broke one set of rules with changes made to another set.
Things got even worse because an end user generally had no clue why a particular page in the application was malfunctioning and would report a system bug. Due to a very poor integration with the rules engine, a programmer would be required to reproduce the bug and see that the rules engine was throwing cryptic (and not handled) error messages which affected the page. After spending all this time in code, the programmer would often find that the Business Analysts broke the code and would have to make them roll back all of their changes to fix the bug.
So in trying to reduce the need for programmers by using a BRE, the project actually gave the programmers more work because they were responsible for diagnosing bugs that were not in their control to create or fix!