Actually, the problem is not singularly the calculation of the payroll which usually is nothing more than some reports. Of course, they might be heavy and all but database engines nowadays can really push data. It is about the fact that there are lots of similar stuff. Like when someone changes something historically, handling "tainting" and generate new accounting instructions. There are soo many use cases.
And you will do most of it in the database. Why? Because to not use set-based logic a la SQL when you handle huge amounts of data is not very smart.
If you wouldn't, you would have to dump ALL the data to the business layer structure and do advanced data operations like joins and so forth there.
Which, while obviously being possible, sucks and kills your mind. Also database client libraries consume lots of memory, and usually they are not the smartest memory allocators(because they don't have to be).
You will probably want to store states during execution and do it in parts, a huge batch either locks up the entire system for an unacceptable duration or makes you end up with a possibly corrupt dataset. Or at least not one you can always trust. So you cannot really do it in total isolation.
It is all in the little horrible details. Details that dawn on you when a system grow. Because it is all about detail.
No, really, there is nowhere else there are as many parameters and settings as in those cases where law is the logic.
The problem is also not their number, but the fact that they cut through abstraction levels the way they do.
Therefore problems often occurs just because you accidentally tried to do good. :-)
You really have to work with this kind of development for a while to realize its specifik set of problems.
On the contrary, the CAD example is one where you kan make beautifully generic code.
With regards to O calculations, they are not very useful in larger systems, they are great for evaluate algorithms. Systems are systems, and delays are far less about optimizing algorithms but knowing how databases indexing, database queries and their client libraries work, how memory is managed and doing stuff in the right order. Normally there are actually very few places where you do anything very advanced, algorithmically or mathematically(if we are talking about accounting).
Believe it or not, I have actually studied computer science and sorry, there are so many times one has to sidestep design principles in these cases.
To translate a syntax into logical constructs is really easy(ANTLR kicks aass, yay) . And actually, the language itself could be considered a programming language.
The problem is that all that haven't gotten you *anywhere* because law is about interpretation and systems about customer demands.
At some point, the law is interpreted, applied to your customers and translated into if...then...else.. . And you and your system will usually not be the ones that interprets it.
The driver is regulations and customer demand, and that often that translates into designing the system in such a way that it, for example generates the least taxation within the applicable legal constraints.
And here you just can't go wild with Monte Carlo simulations, but have to follow the usually very specific methods the certified accountant has specified as being OK. Compliance issues. And every larger customer has their own model...it is really problematic sometimes to try and cram them into the same system.
Building business systems is less about programming and more about system design, designing a system that can survive and even thrive containing with the madness it contains. Because it is by law required to contain it.