8 ms·

Why Is Payroll Hard - Ron Jeffries

108 points by chrismealy 15y ago

AndrewDucker 15y ago
Very true. People wonder why enterprise software takes a lot of developers and long periods of time, and it's because of things like this.
jameskilton 15y ago
Thankfully I've never worked with something this complicated, but it doesn't surprise me (though reading it did give me a good laugh). What I've learned is that when money is involved, any sense of logic and sanity immediately goes right out the window.
chollida1 15y ago
Sounds like the kind of business logic where Prolog would really shine.
- reginaldo 15y ago
  Yes. Sometimes I think a good way to organize an enterprise system would be to make a trivial CRUD "layer" (no validations there) and then write a bunch of Prolog-clause-like rules. The rules would be the big and interesting part of the system, of course. The system would have to be intelligent enough so that, for performance reasons, after input, only the rules that could possibly affect the input would be run. But then in my modest experience these systems are so complex that sometimes for a simple new input you have to validate a whole bunch of things. I currently develop health care related software here in Brazil. Total chaos. Once I was talking to a doctor, and he said engineers think mostly about the patterns but doctors think mostly about the exceptions. I think the same applies to business. The doctor in question of course liked our system but had a huge list of feature requests (to treat exceptions).
- gaius 15y ago
  It was written in Smalltalk.
  - masklinn 15y ago
    C3 was indeed, but payroll systems have been written in pretty much every language under the sun, I'm guessing chollida1 was talking generalities (and the mess described in the article is the kind of stuff you find in every payroll system)
    - chollida1 15y ago
      > I'm guessing chollida1 was talking generalities I was yes.
- Duff 15y ago
  Totally. I used to write event handling rules for the Tivoli Enterprise Console, which used a Prolog dialect and a godawful DSL based on prolog. I had a ton of fun doing it... basically you had to write rules to normalize SMTP traps from various vendors, and take action based on them. Network vendors did all sorts of bizarre things -- one ATM would periodically send a "Interface Down" event, with an attribute set that meant that the "Down" event actually meant up! The hard part was actually doing anything with the events. The regime in charge of my division had a deep seated fear of automatic actions, even actions as simple as opening a trouble ticket.
matwood 15y ago
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 :)
- cpeterso 15y ago
  Don't forget interfacing with third-party systems like banks and insurance providers! :)
hkarthik 15y ago
Healthcare software has the same kinds of problems. New regulations, rules, and ways that each party in the system attempts to skirt the rules bleed into the code bases of every system. Thats why a lot of the technology in healthcare is so far behind. One place I worked at still makes $38 mil/year on a system written in C++ and ASP. Replacing it with a modern stack has been on going process for more than 3 years with no end in site. In the mean time, new installations are being brought up with a whole new set of business rules being added that will just have to get ported later.
- smackfu 15y ago
  For national companies, state level reporting requirements are a huge burden. For instance, payment made to doctors by healthcare companies. You just hope that they pick fairly common requirements, instead of each state reinventing the wheel.
jfruh 15y ago
"The debators of the rules are more interested in satisfying the group than in definition or algorithmic simplicity or purity of concept." This sentence is incredibly useful for understanding why modelling a process hammered out by more than three people will always be more complicated than you think it is.
- masklinn 15y ago
  > This sentence is incredibly useful for understanding why modelling a process hammered out by more than three people Three? I'd go with one. Hell, I'd go with zero, if the one person is a banker or a lawmaker.
edw519 15y ago
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 program logic, and data base normalization to provide structure to that which appears to be unstructured? - How can I use the customer's seemingly unreasonable demands to differentiate myself from mortal programmers? - What do I need to become in order to say "Yes" to my customer whenever I want? - How can I use all of the above to actually encourage my customer to attempt the "undoable" in order to differentiate himself from his competitors?
- nupark2 15y ago
  I came here to say the same thing, and you'd already said it. 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.
- bigsassy 15y ago
  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 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.
  - 15y ago
akeefer 15y ago
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 complications, doesn't suffer from having to exactly model some pre-existing, half-specified, inconsistent process that was developed by humans long before the advent of software.
- hello_moto 15y ago
  ... and this is probably why some tools or some methodologies work in Enterprise but might not work in commercial software.
- gwright 15y ago
  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
  - tryitnow 15y ago
    This is where entrepreneurship comes into play (at least in the long run). Many older enterprises become uncompetitive because of the chaotic absurdity of their systems. This allows upstart new entrants or innovative competitors to eat their lunch.
  - m104 15y ago
    There are many ways to bring some order back into the world, as you say, but it can be a struggle. In my experience, business leaders will support simpler systems and processes if (and only if!) the benefits clearly outweigh the costs. As an IT professional, framing the right perspective is essential to getting acceptance for better systems. Presenting a more powerful, but simpler, system as "losing some rarely used and inefficient features" is a sure way to get that project rejected. Management will only hear the "losing" part as a loss in total value and therefore worse than the current solution. Personally, I like to present formalized system upgrades as the price of growth and future growth potential. Most business leaders can wrap their heads around the concept of "we need to focus and streamline in order to reach the next level", regardless of technical experience.
gbvb 15y ago
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.
- edw519 15y ago
  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. Wow, a new person's first comment hits the bulletin board! You're batting 1.000, gbvb. Welcome aboard.
  - gbvb 15y ago
    :)
- anamax 15y ago
  > 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.
  - gbvb 15y ago
smackfu 15y ago
Another one I saw recently: "Oh, you've worked from that alternate location for too many days this year, so your travel expenses are no longer a business expense. The company will still pay them, but now they are taxable benefits. So the company will actually pay you extra in payroll to offset the taxes you will now have to pay." Oy.
teyc 15y ago
Because of this payroll systems are fraught with implementation problems, particularly in government, where this type of rules exist. 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/ 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-bungle-bill-soars/story-e6freoof-1226178920932 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-fail#comment-72 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 http://delicious.com/search?p=itfailures and http://delicious.com/tag/deathmarch http://delicious.com/tag/deathmarch
- cobrien 15y ago
  Another example of a payroll system implementation gone awry: SAIC's CityTime in NYC [1]. $700mm+ now ... [1] http://www.nytimes.com/2011/11/01/nyregion/bloomberg-administration-admits-mishandling-citytime-and-nycaps-programs.html http://www.nytimes.com/2011/11/01/nyregion/bloomberg-adminis...
mikebike 15y ago
Obligatory Tao of Programming reference (by Geoffrey James) <http://www.canonical.org/~kragen/tao-of-programming.html> http://www.canonical.org/~kragen/tao-of-programming.html&#62...: 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.
zzygan 15y ago
Payroll is a really weird beast. In some ways business apps can be a challenge, and in others a real pain. Payroll is definitely one of the harder business problems to make generic. I've just come off a payroll project that has been 2 and half years in the making, and I can say first hand that all of these things happen. And more. Acquisitions, benefits, and here in AU award wages for hourly employees make things even more fun. Different sites of the same company can have completely different set of rules and regulations that they adhere to, purely because the unions decided to negotiate differently for a different site. Ahh fun.
DanielBMarkham 15y ago
Typical noob mistake #73: trying to make a class out of every rule in a rules-based system. I hate to be blunt (or worse, snarky) but seriously, everybody does this at least once: modeling and factoring out tons of bullshit when the user is really explaining an ad hoc rules system. Very painful. At some point during analysis, you have to ask yourself "Do I really want to make the system more complex for each example of X the user gives me? Or just acknowledge that the user is free to come up with all kinds of crazy rules from now until the cows come home, and code that?" (and simplify)
- glassx 15y ago
  Your reply reminds me of Zed Shaw's presentation 'The ACL is dead'. Basically he said that if the law rules that you have to handle are turing complete, you're probably better off with a turing complete language: http://news.ycombinator.com/item?id=420650 http://news.ycombinator.com/item?id=420650 Of course, procedural code becomes spaghetti code quite easily, but one probably needs the same discipline when doing object oriented/relational modeling...
jodrellblank 15y ago
-- Stories of the Burroughs B5000, http://web.me.com/ianjoyner/Files/Waychoff.pdf http://web.me.com/ianjoyner/Files/Waychoff.pdf He devoted an entire session to the French Railroad payroll program. The French Rail- road had gone on an economy program and reduced their number of employees from 540,000 to 360,000. So that was the size of the payroll that was run on the computer in Paris. That payroll must be the most difficult payroll in the world to run. The size of the payroll is only the tip of the iceberg. An engineer’s (i.e. a train driver) salary is a function of the amount of power that he uses. So if he is on an uphill run, he makes more money than on a downhill run. The employees live in government housing and their rent is deducted from their pay. People with a lot of dependents get more money than people with a few dependents. A vet- eran gets more money for each medal that he won in the war. The amount of money depends on the medal. A Purple Heart is worth more than a Sharpshooters medal.
- Joe_Knapp 15y ago
  Wow. I once did a payroll program for a company of about 600 employees and 5 unions. it to 18 months. After that they changed the union contracts to be more common with each other and simplified the payroll rules.

108 points by chrismealy 15y ago

Very true. People wonder why enterprise software takes a lot of developers and long periods of time, and it's because of things like this.

jameskilton 15y ago

Thankfully I've never worked with something this complicated, but it doesn't surprise me (though reading it did give me a good laugh). What I've learned is that when money is involved, any sense of logic and sanity immediately goes right out the window.

chollida1 15y ago

Sounds like the kind of business logic where Prolog would really shine.

reginaldo 15y ago
Yes. Sometimes I think a good way to organize an enterprise system would be to make a trivial CRUD "layer" (no validations there) and then write a bunch of Prolog-clause-like rules. The rules would be the big and interesting part of the system, of course. The system would have to be intelligent enough so that, for performance reasons, after input, only the rules that could possibly affect the input would be run. But then in my modest experience these systems are so complex that sometimes for a simple new input you have to validate a whole bunch of things. I currently develop health care related software here in Brazil. Total chaos. Once I was talking to a doctor, and he said engineers think mostly about the patterns but doctors think mostly about the exceptions. I think the same applies to business. The doctor in question of course liked our system but had a huge list of feature requests (to treat exceptions).
gaius 15y ago
It was written in Smalltalk.
- masklinn 15y ago
  C3 was indeed, but payroll systems have been written in pretty much every language under the sun, I'm guessing chollida1 was talking generalities (and the mess described in the article is the kind of stuff you find in every payroll system)
  - chollida1 15y ago
    > I'm guessing chollida1 was talking generalities I was yes.
Duff 15y ago
Totally. I used to write event handling rules for the Tivoli Enterprise Console, which used a Prolog dialect and a godawful DSL based on prolog. I had a ton of fun doing it... basically you had to write rules to normalize SMTP traps from various vendors, and take action based on them. Network vendors did all sorts of bizarre things -- one ATM would periodically send a "Interface Down" event, with an attribute set that meant that the "Down" event actually meant up! The hard part was actually doing anything with the events. The regime in charge of my division had a deep seated fear of automatic actions, even actions as simple as opening a trouble ticket.

matwood 15y ago

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

cpeterso 15y ago
Don't forget interfacing with third-party systems like banks and insurance providers! :)

hkarthik 15y ago

Healthcare software has the same kinds of problems. New regulations, rules, and ways that each party in the system attempts to skirt the rules bleed into the code bases of every system. Thats why a lot of the technology in healthcare is so far behind. One place I worked at still makes $38 mil/year on a system written in C++ and ASP. Replacing it with a modern stack has been on going process for more than 3 years with no end in site. In the mean time, new installations are being brought up with a whole new set of business rules being added that will just have to get ported later.

smackfu 15y ago
For national companies, state level reporting requirements are a huge burden. For instance, payment made to doctors by healthcare companies. You just hope that they pick fairly common requirements, instead of each state reinventing the wheel.

jfruh 15y ago

"The debators of the rules are more interested in satisfying the group than in definition or algorithmic simplicity or purity of concept." This sentence is incredibly useful for understanding why modelling a process hammered out by more than three people will always be more complicated than you think it is.

masklinn 15y ago
> This sentence is incredibly useful for understanding why modelling a process hammered out by more than three people Three? I'd go with one. Hell, I'd go with zero, if the one person is a banker or a lawmaker.

edw519 15y ago

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 program logic, and data base normalization to provide structure to that which appears to be unstructured? - How can I use the customer's seemingly unreasonable demands to differentiate myself from mortal programmers? - What do I need to become in order to say "Yes" to my customer whenever I want? - How can I use all of the above to actually encourage my customer to attempt the "undoable" in order to differentiate himself from his competitors?

nupark2 15y ago
I came here to say the same thing, and you'd already said it. 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.
bigsassy 15y ago
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 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.
- 15y ago

akeefer 15y ago

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 complications, doesn't suffer from having to exactly model some pre-existing, half-specified, inconsistent process that was developed by humans long before the advent of software.

hello_moto 15y ago
... and this is probably why some tools or some methodologies work in Enterprise but might not work in commercial software.
gwright 15y ago
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
- tryitnow 15y ago
  This is where entrepreneurship comes into play (at least in the long run). Many older enterprises become uncompetitive because of the chaotic absurdity of their systems. This allows upstart new entrants or innovative competitors to eat their lunch.
- m104 15y ago
  There are many ways to bring some order back into the world, as you say, but it can be a struggle. In my experience, business leaders will support simpler systems and processes if (and only if!) the benefits clearly outweigh the costs. As an IT professional, framing the right perspective is essential to getting acceptance for better systems. Presenting a more powerful, but simpler, system as "losing some rarely used and inefficient features" is a sure way to get that project rejected. Management will only hear the "losing" part as a loss in total value and therefore worse than the current solution. Personally, I like to present formalized system upgrades as the price of growth and future growth potential. Most business leaders can wrap their heads around the concept of "we need to focus and streamline in order to reach the next level", regardless of technical experience.

gbvb 15y ago

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.

edw519 15y ago
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. Wow, a new person's first comment hits the bulletin board! You're batting 1.000, gbvb. Welcome aboard.
- gbvb 15y ago
  :)
anamax 15y ago
> 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.
- gbvb 15y ago

smackfu 15y ago

Another one I saw recently: "Oh, you've worked from that alternate location for too many days this year, so your travel expenses are no longer a business expense. The company will still pay them, but now they are taxable benefits. So the company will actually pay you extra in payroll to offset the taxes you will now have to pay." Oy.

teyc 15y ago

Because of this payroll systems are fraught with implementation problems, particularly in government, where this type of rules exist. 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/ 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-bungle-bill-soars/story-e6freoof-1226178920932 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-fail#comment-72 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 http://delicious.com/search?p=itfailures and http://delicious.com/tag/deathmarch http://delicious.com/tag/deathmarch

cobrien 15y ago
Another example of a payroll system implementation gone awry: SAIC's CityTime in NYC [1]. $700mm+ now ... [1] http://www.nytimes.com/2011/11/01/nyregion/bloomberg-administration-admits-mishandling-citytime-and-nycaps-programs.html http://www.nytimes.com/2011/11/01/nyregion/bloomberg-adminis...

mikebike 15y ago

Obligatory Tao of Programming reference (by Geoffrey James) <http://www.canonical.org/~kragen/tao-of-programming.html> http://www.canonical.org/~kragen/tao-of-programming.html&#62...: 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.

zzygan 15y ago

Payroll is a really weird beast. In some ways business apps can be a challenge, and in others a real pain. Payroll is definitely one of the harder business problems to make generic. I've just come off a payroll project that has been 2 and half years in the making, and I can say first hand that all of these things happen. And more. Acquisitions, benefits, and here in AU award wages for hourly employees make things even more fun. Different sites of the same company can have completely different set of rules and regulations that they adhere to, purely because the unions decided to negotiate differently for a different site. Ahh fun.

DanielBMarkham 15y ago

Typical noob mistake #73: trying to make a class out of every rule in a rules-based system. I hate to be blunt (or worse, snarky) but seriously, everybody does this at least once: modeling and factoring out tons of bullshit when the user is really explaining an ad hoc rules system. Very painful. At some point during analysis, you have to ask yourself "Do I really want to make the system more complex for each example of X the user gives me? Or just acknowledge that the user is free to come up with all kinds of crazy rules from now until the cows come home, and code that?" (and simplify)

glassx 15y ago
Your reply reminds me of Zed Shaw's presentation 'The ACL is dead'. Basically he said that if the law rules that you have to handle are turing complete, you're probably better off with a turing complete language: http://news.ycombinator.com/item?id=420650 http://news.ycombinator.com/item?id=420650 Of course, procedural code becomes spaghetti code quite easily, but one probably needs the same discipline when doing object oriented/relational modeling...

jodrellblank 15y ago

-- Stories of the Burroughs B5000, http://web.me.com/ianjoyner/Files/Waychoff.pdf http://web.me.com/ianjoyner/Files/Waychoff.pdf He devoted an entire session to the French Railroad payroll program. The French Rail- road had gone on an economy program and reduced their number of employees from 540,000 to 360,000. So that was the size of the payroll that was run on the computer in Paris. That payroll must be the most difficult payroll in the world to run. The size of the payroll is only the tip of the iceberg. An engineer’s (i.e. a train driver) salary is a function of the amount of power that he uses. So if he is on an uphill run, he makes more money than on a downhill run. The employees live in government housing and their rent is deducted from their pay. People with a lot of dependents get more money than people with a few dependents. A vet- eran gets more money for each medal that he won in the war. The amount of money depends on the medal. A Purple Heart is worth more than a Sharpshooters medal.

Joe_Knapp 15y ago
Wow. I once did a payroll program for a company of about 600 employees and 5 unions. it to 18 months. After that they changed the union contracts to be more common with each other and simplified the payroll rules.