If the code is clear and it's documented that's probably the best option in most circumstances. The hurdles for making a tenable configuration / logic-as-data system are much higher. Expert/rule-based systems are hard, but usually necessary in most systems of a size.
The question to think about is "how much will this cost the business to change over time?" A developer hour could cost between $30 - 150 / hr depending. For most businesses cost of development completely dwarfs infrastructure/server costs. If a few small changes like accepting options or avoiding hard-coded values takes a tiny bit more time upfront it's worth considering. If you don't know how the procedure will change, best make it clear, concise, and documented so you, or another developer can make it more flexible down the line. This cost and risk of development is also why the "buy first, develop second" strategy tends to be prevalent in IT decision making.
I guess my real pet peeve is that developers tend to make tooling for other developers and don't always put the same effort into non-developer tooling. If you think about the CRUD apps we build- so often it's on a mountain of tooling and abstractions to get it as productive as it is (Database + ORM + Web Framework). We should be focusing that same kind of effort in tooling development at declarative/point-and-click use cases so developer need-to-know out of the change equation more often.
The question to think about is "how much will this cost the business to change over time?" A developer hour could cost between $30 - 150 / hr depending. For most businesses cost of development completely dwarfs infrastructure/server costs. If a few small changes like accepting options or avoiding hard-coded values takes a tiny bit more time upfront it's worth considering. If you don't know how the procedure will change, best make it clear, concise, and documented so you, or another developer can make it more flexible down the line. This cost and risk of development is also why the "buy first, develop second" strategy tends to be prevalent in IT decision making.
I guess my real pet peeve is that developers tend to make tooling for other developers and don't always put the same effort into non-developer tooling. If you think about the CRUD apps we build- so often it's on a mountain of tooling and abstractions to get it as productive as it is (Database + ORM + Web Framework). We should be focusing that same kind of effort in tooling development at declarative/point-and-click use cases so developer need-to-know out of the change equation more often.