> So, what makes a payroll system at this scale so difficult?
Complex pre-existing business rules of a large, sui generis employer (governments, especially sovereign ones rather than localities, often are because the laws that apply to other employees don't apply to them, and the rules that do apply often aren't coherent across-the-board policies determined by a central org focussed on HR, but often are set in special case laws applied to individual subunits of the government by a legislature then operationalized by the HR staff in that subunit) trying to be put in a COTS system make it hard, but probably what makes it most out of control is that the contractor is optimized in maximizing value extracted not efficient delivery and that governments generally suck at overseeing IT contracts (sometimes this is corruption, but it's often just lacking the knowledge and skills to do it effectively at the direct contract management staff level, often complicated by mandated IT contracting frameworks that are based on the underlying assumption that software engineering is basically structurally the same as civil engineering.)
It seems like lots of the payroll was being carried out by humans in local units. Humans are very good at holding lots of exceptions in our heads and, in the absence of clear rules, doing reasonable things. Computers are shit at both of the above.
So things like Bob negotiated with his boss to leave early on Thursday to cover childcare and, in exchange, is coming in early on Tuesdays... but got asked to come in Saturday and now has overtime and what does he get paid based on province or local rules? Does OT end at midnight or not? Do employees get paid non-required OT as a courtesy? And frankly, lots of payroll probably sometimes violates the rules in minor ways, but as long as the employee is happy and the org is happy no-one is upset. Computers are not good at letting small things like that go. And that's a pretty trivial case.
What about eg janitorial that is paid by multiple government orgs on some cost sharing arrangement because the orgs share office space, but is covering an event for a 3rd org in the 2nd org's space? And that janitor is on a particular contract, one of perhaps 5 or 6? If that has to get encoded into a central system, have fun with that. God only knows how many exceptions there are across a quarter of a million employees.
The fundamental problem is when people want software to prevent people from ever messing up instead of simply enabling people to do their jobs better. I heard someone say the other day that they wouldn’t use a simple workflow tool becuase it didn’t provide read only access for other company employees. Look, other people could walk over to your desk and throw all of your papers in the trash too. You still use paper. Why must software prevent malicious actions perfectly?
> Humans are very good at holding lots of exceptions in our heads and, in the absence of clear rules, doing reasonable things. Computers are shit at both of the above.
Which is a remarkably concise summary of my thoughts regarding self driving cars.
When did you form those thoughts? The last 10 years has had pretty monotonic progress in the opposite direction. It seems unlikely for the technology to suddenly stop and certainly not go backwards.
It's that 80/20 rule... I'm sure Canada saw monotonic progress in their payroll system over the last 10 years, too. But with cars, the 20 can kill, not just screw up paychecks.
> does he get paid based on province or local rules?
I believe the answer is "neither". Federal employees are exempted from both. That case would be decided based on federal law and the union contract. It's made more complex by the fact that the union contract is often applied retroactively to events several years in the past due to how long negotiations take.
Corruption is often brought up, and I'm not saying it doesn't happen, but any time I've been consulting, it's always general issues, personal issues, technical issues, refusing to change, all sorts of standard stuff. Not corruption.
It's hard to implement even a minor thing in a large company.
That vendor that has lots of technical issues and the manager that is refusing to change. Well, they know each other and the vendor is giving kickbacks for dragging it out as long as possible.
Most of the corruption in government IT contracting is more subtle; its things like government managers developing relationships with contractors and favoring them subtly without kickbacks, simply because they are comfortable and feel better working with them. The people doing it probably mostly feel like they are actually doing a public good and working around red tape, because they genuinely believe that intangibles that wouldn't be weighed properly in the formal process do weigh in favor of the contractor being a better value.
OTOH, yes, the kind with actual kickbacks absolutely exists, too.
I don't even know if I call that corruption. Humans are the key part of business, and relationships with contractors are just a reflection of that. That absolutely happens, near constantly. I don't think of that as corruption, as much as in a world of very difficult success, when someone proves they can be successful, and make you feel confident, it makes logical sense to stick with them.
Complex pre-existing business rules of a large, sui generis employer (governments, especially sovereign ones rather than localities, often are because the laws that apply to other employees don't apply to them, and the rules that do apply often aren't coherent across-the-board policies determined by a central org focussed on HR, but often are set in special case laws applied to individual subunits of the government by a legislature then operationalized by the HR staff in that subunit) trying to be put in a COTS system make it hard, but probably what makes it most out of control is that the contractor is optimized in maximizing value extracted not efficient delivery and that governments generally suck at overseeing IT contracts (sometimes this is corruption, but it's often just lacking the knowledge and skills to do it effectively at the direct contract management staff level, often complicated by mandated IT contracting frameworks that are based on the underlying assumption that software engineering is basically structurally the same as civil engineering.)