Why Is Payroll Hard - Ron Jeffries • Hacker News Board

Re: Why Is Payroll Hard - Ron Jeffries

#51

Post by Confusion » Thu, Nov 17, 2011, 7:55 AM UTC

bena wrote: post #27

bigsassy wrote: post #24

Earlier quoted context omitted.

My first job out of college was with a consultancy that specialized in payroll integration projects. We were a partner with ADP (largest payroll provider in the country), and typically they sent us the clients with the trickier payroll processes, so know I'm speaking from experience. Long story short, I agree with what you're saying, but you make it sound like it's really simple. It's not. Creating a single payroll s…

Basically, if you think it's simple, you haven't thought about it.

Not thinking about it is not the problem. A lack of domain knowledge is. If you don't know how payrolling actually works in practice, no amount of thinking will make you come up with the right solution. The real pitfall here, and the downfall of many startups, is thinking you can understand the domain merely by thinking about it. Engineers can usually think pretty well and can solve many problems in that way. It's crucial to realize not everything can be solved by thinking about it.

Re: Why Is Payroll Hard - Ron Jeffries

#52

Post by YourAnMoran » Thu, Nov 17, 2011, 8:36 AM UTC

edw519 wrote: post #12

I love stuff like this! Instead of complaining about the structure or motivation of business rules, excellent developers ask different questions: - How can I design my architecture to accommodate just about anything my customer throws at me? - How can I use all the tools in my tool box (including CS and math concepts) to clarify the apparently nebulous? - How can I use things like Boolean algebra, parameter driven pr…

> How can I design my architecture to accommodate just about anything my customer throws at me?

Poor attempts at this will result in very complex systems with unnecessarily many layers of indirection which still can't accommodate to the most peculiar business requirements thrown at them. It's like having the worst of both worlds, overengineering and dirty hacks.

Re: Why Is Payroll Hard - Ron Jeffries

#53

Post by onemoreact » Thu, Nov 17, 2011, 3:01 PM UTC

bigsassy wrote: post #32

onemoreact wrote: post #31

Earlier quoted context omitted.

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 s…

You make two assumptions: 1) There is "one" way of representing payroll data. There's not. When you get a none trivial amount of clients, all their edge cases put together destroy any ability to fit the data into one conceptual model elegantly. 2) Companies have control over payroll rules. Large companies often can't simplify their systems due to contracts or the subsequent employee mutiny. Unless you want to get sue…

1) The only conceptual model I think needs to apply is the how things are taxed. Granted some organizations have edge cases in how they pay taxes (or how they try to hide things) but I think innate complexity dominates unique edge cases when it comes to the tax code.

2) I would argue that much of this complexity shows up because many companies negotiate while ignoring the cost of adding complexity. Company wants to minimize cost, workers want to maximize benefits, complexity is a dead weight that benefits nobody. Once things have been negotiated it's hard to change, but during negotiation they is no need to end up with yet another edge case.

PS: I don't think organizations end up spending 100+ million on their payroll systems because it's easy. I just think being proactive lets some companies minimize those costs. EX: Is Google's payroll system ugly?

Re: Why Is Payroll Hard - Ron Jeffries

#54

Post by anamax » Thu, Nov 17, 2011, 11:12 PM UTC

gbvb wrote: post #30

anamax wrote: post #26

Earlier quoted context omitted.

> 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 hav…

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.