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:

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:


See also: EmployeeTypes, PayrollExample


EditText of this page (last edited November 16, 2011) or FindPage with title or text search