In February of 2008, I had written an article called Time to Market is Still Everything which was basically a response to an approach to writing software that I had encountered previously.
The approach can be summed up as hanging a very large number of fields off of the main entity tables in your database and writing your application such that the decisions made in the business rules are driven by those fields. This is no way to write software because it takes too long to implement and assure quality. Why? It’s all in the combinatorics. Even if you only used boolean fields and you only had to apply logic that checks each field once, you would still have a system with exponential complexity. You throw in the real-world facts of other types of decision fields such as dates and amounts, with non-intuitive edge conditions, and the fact that a business rule depending on any such field may have to be implemented with slight variations in more than one place in the code, and you end up with a logistics nightmare.
So, it takes a long time to deliver. Why is that a problem? It’s a problem because software requirements have a surprisingly short shelf life. Markets change. Businesses change. So the software that runs business must adapt to these changes or risk becoming irrelevant.
Another problem with this data driven business logic approach is you end up spending a lot of time and resources developing features that any individual business just doesn’t care about.
Finally, these types of systems are typically resistant to change over time. They become rigid and break easily since developers can’t study the code in order to assess the impact of any proposed enhancement.
When you really diagnose a design where there are lots of these decision support fields, you will find a situation where the corporate culture just doesn’t support its people making decisions. Successful software projects are staffed by people who are humble enough to really listen to their customers yet assertive enough to not be afraid to make decisions about what the software really needs to do. Deferring a decision to a user editable field is the coward’s way out.