21–30 of 54 posts
I just built an internal payroll system for my company. It's been a huge pain because it involves both parts of the business I generally try to avoid - legal, and dealing directly with money. Oh, a big item missing from the list is dealing internationally. If you think navigating all the state and local laws are hard wait till you look at another country :)
In the past I kept a log of IT project failures as I come across them. There are a few bad payroll system rollouts. http://it-project-failures.blogspot.com/
The Queensland Health Payroll system blew up a political storm because of implementation issues. The cost of the blowout? $219M. http://www.couriermail.com.au/news/queensland/health-pay-bun...
In fact there was an inquiry into what went so badly wrong http://www.insightcp.com/blog/why-sap-hrpayroll-projects-fai...
Payroll systems should never be migrated wholesale. They should be scriptable, for instance pay masters should be able to script the computations to assist them.
Anybody else interested in IT project morbidity could also look at http://delicious.com/search?p=itfailures and http://delicious.com/tag/deathmarch
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…
I too love problems like this. A properly designed system like this one will account for every possible oddball situation you can come up with -- and if it can't support an especially weird solution out-of-the-box, it will be easily extensible such that it can.
Too many people code to the goal and don't try to model the underlying logical concepts.
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…
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 solution to handle one company is very easy. Creating a single payroll solution to handle many companies is also quite doable.
But once you get to the scale of ADP, it's impossible to handle everyone elegantly. Between union contracts and non-standard practices, there are (what felt like) an infinite number of things a customer can throw at you, with one rule wackier than the next.
It's damn hard to write a generic payroll solution that handles most companies. Damn hard.
Pretty much all "enterprise software" is fundamentally the art of taking totally irrational, human-defined, fuzzy, incompletely-specified pre-existing processes that have been built up over decades or centuries, and turning them into an automated system that functions more or less identically. It's fundamentally different than doing something like writing a word processor or e-mail client which, while it has its own…
refactoring
version control
DRY applied to laws and contracts
diff tools for laws and contracts
standard interfaces
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…
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.
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…
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…
Pretty much all "enterprise software" is fundamentally the art of taking totally irrational, human-defined, fuzzy, incompletely-specified pre-existing processes that have been built up over decades or centuries, and turning them into an automated system that functions more or less identically. It's fundamentally different than doing something like writing a word processor or e-mail client which, while it has its own…
I often wish there was some way to inject some order back into the real world systems. So many of the techniques and processes that developers take for granted seem entirely absent from our regulatory and administrative law systems: refactoring version control DRY applied to laws and contracts diff tools for laws and contracts standard interfaces
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: ``Which is easier to design: an accounting package or an operating system?''
``An operating system,'' replied the programmer.
The warlord uttered an exclamation of disbelief. ``Surely an accounting package is trivial next to the complexity of an operating system,'' he said.
``Not so,'' said the programmer, ``when designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design.''
The warlord of Wu nodded and smiled. ``That is all good and well, but which is easier to debug?''
The programmer made no reply.
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…
> 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…