Hacker News Reader

Comment by gbvb | Hacker News Reader

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 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.

View on HN

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.

But most people have complicated personal banking set-ups with money flowing in and out to different places at different times. It works well because the individual has control. If you had to automatically pay for your shopping using some database magic every week, instead of just handing over a credit card it wouldn't work either.

Treat payroll like an individual bank account with facilities to make and receive payments automatically. Then let actual humans enter the information individually for each person. Add automation of this as an after thought once the problem is fully understood.

I am really not underestimating the effort. But there are multiple pieces to what you just talked about. There are complexities in time measurement (or computing how much work was done) and in payroll calculation.

When systems of this sort are built, it is usually a combination of Timekeeping (how to measure time spent on the job) and payroll (how to pay for that time). Each section is a big (i.e. millions of line of code and many engineers) worth of effort. All that said, depending on how systems are built, you can a) Create a base system that solves core issues b) Accomodate as much configuration towards that system to allow computation to occur differently based on what the employees do c) Allow customizations of computation when as required d) Make most of the data that can be changed, to be changeable through design (data driven instead of code)

Of course, there will be customers who will want to behave differently because the moon is in a certain position in the system. But, that is when you need to know the domain enough to understand whether what they are asking for is because "that is how they have always done it" or because there is a valid use case that needs one of the b), c) or d) to be updated.

> 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).

Except when it isn't. For example, some folks have multiple roles, covered by different unions, with different rules. Those rules are applied to different parts of their "total wage". I suspect that some wages don't count for 401(k). And so on.

None of these things necessarily have simple definitions and they interact in complex ways. Any "general model" is likely to be wrong and seemingly minor changes can have huge consequences.

Actually, it is feasible. It is possible to do this still. Solve it with a model to start and chain the calculation events. You can re-iterate based on the different situations. The design, when thought through, can be accommodating such variations. It is definitely a lot of work (dont get me wrong). If this was not feasible, there would be no Payroll vendors. :)

> Actually, it is feasible.

I never said otherwise.

> It is definitely a lot of work (dont get me wrong).

We agree.

My point is that the models are brittle because every entity (govt, unions, etc) has different definitions for every one of the "common" terms, can change their definitions, and the scope is very context and usage dependent.

Wow, a new person's first comment hits the bulletin board!

You're batting 1.000, gbvb. Welcome aboard.

Reply on news.ycombinator.com