3 ms·

This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases). I.e. when a frequently c

This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases). I.e. when a frequently changing business process like a finite state machine for an approval procedure is only change-able by a developer that means there's always the cost of that developer's "need-to-know" for a straight forward change in the business operations. The cost of a given change is greater than a declarative capability that took into account operational changes in the first place. That said hard coding business logic is often so much quicker to deploy that in many situations you just want to hard code the logic, deploy, get feedback, then introduce flexible to the kind of change needed then continue. If you have engineers who know how to ask the kind of questions that get to the real requirements (usually not juniors) you can have a maintainable code base. Worst case scenario is if you have the "yes I shall do anything and everything with my new code power" developers who just implement out of eagerness and conflict avoidance; this can be the worst of every world: hard coded business logic so convoluted only the junior knows how to make changes.

crgwbr 7y ago
> This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases). I’ve built systems both ways. Requiring a developer to make changes definitely has costs, but it does have benefits as well. Systems configured in data rather than code will almost invariably be untested and prone to configuration bugs. Overall, I’ve spent probably double or triple the time debugging configuration of complex business rules systems than I would have if it was just written in code and unit tested.
- mrdoops 7y ago
  Agreed. I guess my point is that we need to focus more on making declarative business rules systems more tenable as an approach in general. If we consider the framework + CRUD generators as the most productive way to build a web app (probably has been since Rails) - that's a result of tooling built around an approach. What happens when we focus similar efforts of tooling towards these Rule Based components?
- closeparen 7y ago
  One cool trick here is to use a restricted subset of a programming language as your rules configuration format. That way it still feels accessible to stakeholders, but you also have access to the other software development paraphernalia (tests, static analysis, version control, etc) if you want it.
WhompingWindows 7y ago
I'm not the most experienced, can you highlight why it'd be wrong to do the following. Let's say you use hard-coded business logic, but you clearly document the code and it'd be clear to any experienced programmer what's going on. How is that un-ideal? Yes it's non-transferrable code, but it's so much faster to write purpose-built code, right?
- mrdoops 7y ago
  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.

crgwbr 7y ago

> This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases). I’ve built systems both ways. Requiring a developer to make changes definitely has costs, but it does have benefits as well. Systems configured in data rather than code will almost invariably be untested and prone to configuration bugs. Overall, I’ve spent probably double or triple the time debugging configuration of complex business rules systems than I would have if it was just written in code and unit tested.

mrdoops 7y ago
Agreed. I guess my point is that we need to focus more on making declarative business rules systems more tenable as an approach in general. If we consider the framework + CRUD generators as the most productive way to build a web app (probably has been since Rails) - that's a result of tooling built around an approach. What happens when we focus similar efforts of tooling towards these Rule Based components?
closeparen 7y ago
One cool trick here is to use a restricted subset of a programming language as your rules configuration format. That way it still feels accessible to stakeholders, but you also have access to the other software development paraphernalia (tests, static analysis, version control, etc) if you want it.

WhompingWindows 7y ago

I'm not the most experienced, can you highlight why it'd be wrong to do the following. Let's say you use hard-coded business logic, but you clearly document the code and it'd be clear to any experienced programmer what's going on. How is that un-ideal? Yes it's non-transferrable code, but it's so much faster to write purpose-built code, right?

mrdoops 7y ago
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.