Some WikiZen''''''s have suggested that computer-aided compile-time "validation" and heavy reliance on type-checking of code is a GoldenHammer, or at least a silver hammer. 

However, a lot of the logical contradictions and problems in software I encounter involve '''domain issues''' that the domain user(s) ''should be'' involved with because as a developer I cannot be effectively involved in the day-to-day business issues that require fairly complex or detailed domain decisions. I have too many "techie" issues to deal with. The domain power-users are the better choice because they know the domain. This is especially true in an organization divided into regions, cities, etc. where each area needs a location-specific domain expert with some control over custom business logic. 

It might be great job security for me to help in the minutia of the marketing department's matching of coupons for socks with neckties, but that's not the best skill allocation. Sure, there's always exceptions that need the attention of the tech-side developers, but if we keep those down to say 10% of all needs, then we can focus more on technical issues.

The problem is that a compiler-centric approach is beyond what most domain users can relate to. You can't expect them to learn some kind of application programming or AI language.

I therefore tend to focus on '''attribute-driven meta-data (ADMD)''' that a domain power-user can relate to, somewhat along the lines of TableOrientedProgramming and BusinessRulesMetabase. Many power-users can relate to attributes in tabular form or tree-plus-table form. It can offload the bulk of the business rules, leaving the fancier or rare stuff to formal developers. Essentially it is creating a DomainSpecificLanguage of sorts and I as the techie make the domain-specific "interpreter" that "runs" the domain expert's or power-user's "code".

And special "suspicion reports" can be built to show issues that need further attention. Using type-checking for such things is often too blunt an instrument for integrity. Warnings are easier to formulate than compiled rules. Warnings are '''"fuzzy" or soft checking''' and thus can be created without too much risk. The good road-tested warnings can then graduate to formal rules that stop processes when found. The power-users could perhaps make that choice also.

Thus, this approach potentially has a leg-up over the "linguistical" approach suggested by the "compile" side. (It's still in the experimental stage, so I promise no instant magic, although established tools like SAP's suites have a form of this and I've seen custom versions applied in limited levels. The hardware is just now catching up to a heavy data-driven approach without requiring tedious optimization.)

Perhaps we could split an app into domain issues and computational issues and use ADMD for the domain side and language for the computational side. However, I'd rather leverage existing ADMD for the computational side also, where convenient. It's a better reuse of existing tool-sets and skill-sets.

Further, if the rules are '''dynamic''', then waiting for a compile stage to verify everything and/or publish fixes is not realistic. ADMD seems better suited to dynamic biz rule changes.

--top

--------
'''Third Layer'''

In my observation, the hard dichotomy between developer and user is out-dated. Things are complex enough that there needs to be a third layer, sometimes called a BusinessAnalyst these days (although the term is overloaded). They can deal with many if not most business rules and business logic issues if given the right tools without being "hard-core techies". I've seen power users do amazing things, and if given a little help they will happily handle many of the details that a "traditional" developer normally deals with. 

Traditional Approach:
  [developer]<------>[end-user]

Layered Appraoch:
  [developer]<----->[domain-analyst]<------>[end-user]

The one thing many power-users have in common is that they relate to '''spreadsheets'''. Thus, meta metaphores or DomainSpecificLanguage''''''s based around grids, tables, and sheets are easier for them to digest and relate to.

--top

-------
See also: BusinessRulesMetabase
-----
CategoryDebugging, CategoryException, CategoryUserInterface, SufficientlyFlexibleAppsResembleInterpreters