Why Is Payroll Hard - Ron Jeffries

I seems like the general system is something like:

A) A set of tools to talk with external systems B) A set of tools for manipulating the internal representation of payroll data C) A GUI for interacting with / managing the system.

When their internal process is simple managing the payroll system should be simple. When their internal process is complex you get fat consulting checks. Which brings up a great point, it seems like large companies that simplify their internal systems could avoid writing a lot of consulting checks, so I suspect they must be out there and you just don't hear about.

Having spent the last 9 1/2 years working on systems for property and casualty insurers, I have to say that I don't really agree with everything.

I generally agree with the point about designing your architecture to accommodate whatever gets thrown at you, but doing that is hard. Immensely hard. Nothing is concrete, everything is some extensible meta-problem, where instead of writing code to do X, you have to think "how can I make it so my customers can do X, but can also change it to do Y instead." And of course, they want it to be easy to make it do Y instead. Do you just make them write custom code? Do you enumerate all possible options in a declarative fashion and let them choose between them? It's never easy.

The bits about finding structure in what's unstructured, though, I find to often be exactly the wrong mentality, though it's usually the mindset all engineers start with. The best approach in my experience is usually to just embrace the fact that everything is arbitrary, and recognize that you're just going to be writing a lot of if statements (or giving your customers ways to write if statements); otherwise, you'll inevitably A) run into some situation your nicely-structured algorithms can't handle and B) be endlessly frustrated by the exceptions. The processes being modeled by enterprise software are fundamentally irrational, illogical, inconsistent, and arbitrary. Accepting that, and building systems that can handle that, are hard things for engineers to do, since the tendency is to always try to find patterns and order and simpler, more general algorithms.

Not all problems in enterprise software fall into that category, so it's critical to be able to identify which sort of problem you have: is it one that's structured and makes sense? Then write code accordingly. Is it modeling some pre-existing human process? Then expect that the crazy exceptions you've heard about so far only comprise 1% of all the crazy exceptions out there, that you don't even know how to categorize what those exceptions could be, that there's no real underlying order, and that your job is to write the system in such a way that it can handle the fact that the process is arbitrary.

I guess I wasn't clear. I realize that businesses need to survive in the eco-system created by crazy laws and ill-thought out regulations and contracts.

I was trying to suggest that the legal and regulatory framework is what needs to be fixed, not the businesses.

Ah, look at that, I totally misread where you were going! ;-) In my experience, regulations and crazy laws aren't really a competitive advantage or disadvantage because all of the market players are playing by similar rules. I'm not saying that there's no negative effect to bad regs and laws, but the costs are shared fairly equally.

I've never worked at a business that was cut off at the knees by new laws or regs. I'm sure it's happened, but I'm not convinced it's common. What I have witnessed though, many times at many employers, is pure self-inflicted complexity. The did-they-even-consider-the-cost kind of complexity that is nightmarish to implement and hampers future changes.

As an IT pro I can't do much about the laws and regulations, but I can advise and design business systems in ways to avoid complexity traps and help accommodate more sane business processes.

They get nasty. You cannot underestimate the complexity that collective bargaining agreements bring.

New York City, as an example, has something like 15,000 variations for payroll categories. Plus garnishments, domestic relations orders, etc.

How do you compute the extra boot benefit for a fireman who has worked more than 526 hours in a 13 month period?

Or how to you compute the salary of a garbageman who is paid by the ton of garbage hauled, instead of the hour. Except for when they haul ashes, in which case the tonnage is adjusted, or on Sundays, where they get overtime as well. What are the business rules for an ash hauling garbage guy earning overtime on Sunday, which is also a holiday?

The NYC consolidated payroll system, "CityTime"... has cost over $700M since 1996 to build. (That included some serious fraud.) Fraud aside, Accenture was raping & pillaging too -- charging $400/hr for college grad coders.