On many project, I have seen the following logic...
- Lets have a easy scripting language or visual programming lanuge so non-programmers can customize the system.
- We currently have to have programmers put in custom code for each customer's need and it is expensive.
- We'll let the analyst at the customer's company do the change instead so it is easy and inexpensive.
What is wrong with this picture?
There are two types of changes to systems, configuration parameters, and code.
A configuration parameter is usually a single number or setting that has a very limited set of valid values. For example the department names in a company. Some programmer has thought out in advance what all the possible valid values will be and designed the program to handle them.
The second type of change is the one that causes the most trouble. It is a change in the logic and processing of the program. For example, maybe a 'if' statement that then calls any method available in the program to do processing. Such changes can bring down the whole house of cards that is the program.
Programmers deal with this by knowing the system well, making changes and debugging and testing.
The Flaw
The desire of management is to make such changes easy for a non-programmer. But there is a basic contradiction here. They want a person that does not know the code well, to make the change and not thoroughly test the whole system for interactions.
The Reality
What happens in the real world of product roll out, customer complaints, and emergency fixes to save the sales reps. account, is that the customer quickly gets the application into a state where is will not run, and then a programmer from the company ends up making the change, only now it is some 'scripting language' that is less flexible and powerful than the native language of the application.
The Exception
There is one exception in the real world to this logic, Excel.
Excel is the most widely used programming language in the world and is used mostly by non-programmers.
Why does this exception exits?
Because Excel spreadsheet language is a highly domain specific language in it's simple form. It lets you do simple math on cells. There is no sequential programming being done, no 'if' statements, and a highly limited and sanitized method set. If you make a mistake it tends to be located in exactly the cell you are editing.
Then Excel has deeper programming constructs which most users never use. Thus in some ways it is not being used as a programming language so much as simply customizing settings on cells, which are simple math.
The Secret Solution
There is a sweet spot of customization where the user is not programming, but simply customizing settings. If you can reduce your customers job to 'configuration' then you win.
So here is Keene's Rule of Customization:
"Only let your customer configure."
TF
