I think I have worked on all these architectural burdens, and created a few myself. Come to think of it I developed my own rule management engine (also for an ETL process) where the rules were represented as SQL statements. At least I used an ISO standard language. :)
Probably my most painful designs were the ones where I built a framework for the app. You had to plug your object into it to have plumbing automatically handled for you. That would be fine, except the next feature request was usually an uncommon case. Then I ended up having to refactor the framework to handle it. Then the objects you plug in end up depending too much on the way the framework operates, so they have to be refactored too. This experience is why I now prefer the framework-less approach to the apps I build, and functional programming in general. It can be a little more work up front, but way easier to maintain.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think I have worked on all these architectural burdens, and created a few myself. Come to think of it I developed my own rule management engine (also for an ETL process) where the rules were represented as SQL statements. At least I used an ISO standard language. :)
Probably my most painful designs were the ones where I built a framework for the app. You had to plug your object into it to have plumbing automatically handled for you. That would be fine, except the next feature request was usually an uncommon case. Then I ended up having to refactor the framework to handle it. Then the objects you plug in end up depending too much on the way the framework operates, so they have to be refactored too. This experience is why I now prefer the framework-less approach to the apps I build, and functional programming in general. It can be a little more work up front, but way easier to maintain.