3 ms·
There's another point of view regarding this issue. Complex applications tend to evolve towards an 'inner platform'/'duck programming' state because serious po
by danbmil99 15y ago
There's another point of view regarding this issue. Complex applications tend to evolve towards an 'inner platform'/'duck programming' state because serious power users want to avoid repetitive point/click operations. They demand a programmatic way to macro common tasks that they wish to apply to large amounts of data.
One might say at this point ok, the application should provide an API, and the power user should hire a part-time programmer to write a plugin. But that may not be feasible, and it misses the point that the user may not want to hire programmers and learn about API's.
The deeper question it seems to me is, is it always a sin to allow an end-user to have access to a Turing-complete, user-domain set of tools that are effectively a programming platform?
An answer of yes to this question smacks a bit of elitism: we are the priests of code; users must forever be relegated to pointy-clicky automatons.
- raganwald 15y agoThe article does not suggest that users should not have the power to be programmers, it suggests that the organization benefits from wrapping programming in certain risk management practices and that this is just as applicable to duck programming as it is to code programming.
- demallien 15y agoHeh. I'm fighting against the introduction of a duck programming system at the moment. My cunning plan is to make the system generate source code from the config files. That makes it clear that modifying XML is the same thing as modifying source code, because it explicitly makes modified source code that then needs to be deployed. I may have to post the results on HN :)