Why Is Payroll Hard

Often, people hear about a payroll system (such as C3) and think - that must be a really simple system.

It isn't.

To give a feel as to why, here is a message by RonJeffries snipped from comp.object (http://groups.google.com/group/comp.object/msg/46061876e4bcb44e)

XP claims to produce good design as a side-effect of the refactoring process. I may be wrong but a 2000 class Pay Roll system sounds like a *poor* design. Sorry but this is my gut feel, 2000 classes is really huge, battle ship management maybe not pay roll! Please convince me I'm wrong.

I once thought payroll was simple too. It turns out that it is essentially complex, because of all the special deals and weird practices that have been set up over years of union negotiations and HR people with strange ideas.

For example, these are pretty accurate:

People in Dayton get paid differently from people anywhere else.
Ex-Jeep employees accrue certain benefits six months out of phase with everyone else - or is it a year?
There are five people whose union dues are different from anyone else. No, really.
There are about seven unions, each with different dues rules.
The UPGWA (you-pig-wa) United Plant Guard Workers of America have two tiers of workers, based on time of hire. The old guard (sorry) get a better deal than the new ones.
There are something like 5 different savings plans, with accounts before and after taxes, matched and unmatched, each with maximum and minimum contribution based on company and government policy.
Health insurance includes one of those menu deals where you can pick all kinds of combinations. And there's FLEX, where they give you money you can use for all kinds of medical stuff.
The wage attachment system is a separate knowledge-based system that must be talked to over sockets.
The Human Resources information (wage base, hiring dates, etc) is a separate relational database that must be queried as the payroll runs.
There are several hundred unique transactions that can come into the system. Each must be done in order, and must be separately accounted for. They all can be wrong so each must have unique validation.
If the employee doesn't get enough money to pay all his deductions (something we've all worried about as we look at the tax items), there is a special order in which things must be taken. Some are totally taken, some partially, some have to be skipped. There is no logic to this. The employee is last on this list, of course. I am not making this up.
Everything has to generate transactions for the general ledger. The general ledger keeps accounts completely differently from payroll, so they're all special calculations.
There are approximately 3,000 unique fields of information produced for each paycheck, going downstream to various COBOL programs. Most of these fields are complex, i.e. they are some strange calculation like (base pay unless the guy is on sick leave, in which case it's his number of children) (well, almost). They are variously output in EBCDIC, COMP-3, etc. The program runs on an ASCII machine.
There are approximately 50 states and 300 communities' taxes to be dealt with, including reciprocity. (If you work in A and live in B, you can pay the lower of the two communities' taxes. But if you live in B and work in A ...).
There's profit-sharing, which is calculated based on a formula made up days before the checks come out, and having little relationship to anything previously computed.
There's the Disability program. After being sick for 3 days (when your pay comes from your normal account), you go on disability, where your pay continues but comes from another account. After N days you only get 60% of your pay, unless you come back and go out on a different disability. Payroll is never informed when someone comes back from disability until after at least one check has gone out based on the wrong account. So the payroll has to back out the figures from the disability account and apply them to the regular. Then it turns out the guy isn't back after all.
Transfers to and from this payroll to one of the other six (6) occur at random. You have to accept whatever useless input they give you and simulate the guy being in your better payroll from the beginning. If he leaves, you have to pack up your info and stuff it into the few smashed-together fields the other old program wants. If the guy transfers back, they want to use any good data you may have but to simulate the rest.
Sometimes they get two copies of the same individual in the system for a while, sometimes in the same payroll, sometimes in different ones. You have to sort it out.
- 2 paychecks, woohoo!

Well ... that's all I can remember offhand ... I haven't worked there for almost a year. But you get the idea.

These are real complexities, but they are still mostly imposed by interfacing with an outside system. Hopefully, you could create boundaries around the messiest interfaces. You might still have 2000 classes, but they don't have to be poorly-designed.

What's so bad about bartering?

MartinFowler says that "business logic" is an oxymoron, because businesses are run in very illogical ways. Whether it's payroll, sales, contracts, financial accounting, or whatever, an enterprise-level system is full of hundreds or thousands of special cases, and new special cases are being added every week. Some of these are due to changes in government regulations, but most are due to someone somewhere needing to make a special deal in order to get business or to prevent strikes.

Under AreBusinessAppsBoring, I suggested that with biz apps one is generally modeling a manager's, owner's, or lawmaker's mind(s) rather than say the laws of physics or math. There are often messy negotiations and compromises when the rules are made. The debators of the rules are more interested in satisfying the group than in definition or algorithmic simplicity or purity of concept. They figure technicians are cheaper than their salaries, so it is allegedly better to dump complexity on them rather than complicate or extend the negotiations to simplify. However, what they don't realize is the longer-term fallout due to complexity-induced bugs and confusion even among non-techies when trying to figure out the results. But it may be a case of FutureDiscounting.

Technicians are cheaper than a nation-wide strike. Lawmaker's minds are difficult to fit into our etricate models not because these minds are crazy or whatever, but because they are human beings and they can't be easily modelled using strict hierarchies. And that's great news, by the way! In any case this is our job to make their business understood by the software, not theirs. The typical attitude of "You are presenting problems I can't easily solve with my favorite tool, therefore you're an idiot" should be banned from IT.

Perhaps, but excessive complexity will bite back eventually. Complex/convoluted systems that mirror complex/convoluted business rules are job security for the techies, so most probably won't care either way. It's tax-payers who are hurt the most. Technology itself can only hide so much complexity, and the rest leaks out the other end as ugly sludge.

University of Wisconsin System, more payroll headaches in the news:

http://www.chicagotribune.com/news/chi-ap-wi-uwsystempayroll,0,2597575.story