11–20 of 54 posts
Sounds like the kind of business logic where Prolog would really shine.
It was written in Smalltalk.
Instead of complaining about the structure or motivation of business rules, excellent developers ask different questions:
- How can I design my architecture to accommodate just about anything my customer throws at me?
- How can I use all the tools in my tool box (including CS and math concepts) to clarify the apparently nebulous?
- How can I use things like Boolean algebra, parameter driven program logic, and data base normalization to provide structure to that which appears to be unstructured?
- How can I use the customer's seemingly unreasonable demands to differentiate myself from mortal programmers?
- What do I need to become in order to say "Yes" to my customer whenever I want?
- How can I use all of the above to actually encourage my customer to attempt the "undoable" in order to differentiate himself from his competitors?
Everything that you do is toward satisfying those requirements. It is hard because each of these pieces are influenced by human interaction. But, that does not mean there are no rules of engagement. e.g. If you have union dues to be deducted, it is a formula to compute it against the total wage you make (or it is a flat deduction amount). If you are paying towards 401k, it is a percentage that you put in towards that.
If you imagine the problem as something to solve in a general sense, you can narrow the problems to fit into models. But, if you treat every requirement as a modification to an excel macro (:-D), then you are in trouble.
Oy.
Pretty much all "enterprise software" is fundamentally the art of taking totally irrational, human-defined, fuzzy, incompletely-specified pre-existing processes that have been built up over decades or centuries, and turning them into an automated system that functions more or less identically. It's fundamentally different than doing something like writing a word processor or e-mail client which, while it has its own…
Healthcare software has the same kinds of problems. New regulations, rules, and ways that each party in the system attempts to skirt the rules bleed into the code bases of every system. Thats why a lot of the technology in healthcare is so far behind. One place I worked at still makes $38 mil/year on a system written in C++ and ASP. Replacing it with a modern stack has been on going process for more than 3 years with…
Earlier quoted context omitted.
It was written in Smalltalk.
C3 was indeed, but payroll systems have been written in pretty much every language under the sun, I'm guessing chollida1 was talking generalities (and the mess described in the article is the kind of stuff you find in every payroll system)
I was yes.
Actually, Payroll systems can be structured. In the end, there are only 3 things that you need to provide: - compensation (money employee makes) - deduction (money employee gives for some service) - taxes (employee owes the government) Everything that you do is toward satisfying those requirements. It is hard because each of these pieces are influenced by human interaction. But, that does not mean there are no rules…
Wow, a new person's first comment hits the bulletin board!
You're batting 1.000, gbvb. Welcome aboard.
Actually, Payroll systems can be structured. In the end, there are only 3 things that you need to provide: - compensation (money employee makes) - deduction (money employee gives for some service) - taxes (employee owes the government) Everything that you do is toward satisfying those requirements. It is hard because each of these pieces are influenced by human interaction. But, that does not mean there are no rules…
If you imagine the problem as something to solve in a general sense, you can narrow the problems to fit into models. But, if you treat every requirement as a modification to an excel macro (:-D), then you are in trouble. Wow, a new person's first comment hits the bulletin board! You're batting 1.000, gbvb. Welcome aboard.