The Build-Use Gap
Asking end users to create their own tools is always a red flag simply because the skill, knowledge and expertise required to build a tool is very different and often much, much greater than the skill, knowledge and expertise required to simply use a tool. Indeed the gap between the skill required to build a tool and the skill required to use a tool defines the effectiveness of the tool in itself. When this gap is large the tool is a tremendous value-add, often enabling what would otherwise be impossible. When it’s small the tool is just a convienience. The most valuable tools are necessarily those that lots of people can use but only a few can build. The build-use gap is a useful concept that can be applied to almost any buy/build dilemma. Perhaps the strongest argument against asking non-technial users to write what are effectively business applications isn’t so much that it’s too difficult (though it often is) or that it might lead to overly complicated systems (though it almost always does) but rather to emphasize just how much the end users would have to learn to reach a point where they could confidently build, test, deploy and then finally use their own tools. Users are always hankering for more power, more flexibility, and more freedom and these are generally good things but with great power must come great responsibility. In the end there’s no such thing as “end user programmers” any more than there are “end user auto mechanics” and “end user electricians” — there are simply programmers, auto mechanics, and electricians some of which know what they’re doing and many of which often don’t.