Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #11890 > unrolled thread

How difficult is a payroll system?

Back to article view | Back to comp.misc

Contents

  How difficult is a payroll system? Sylvia Else <sylvia@not.at.this.address> - 2016-09-01 12:04 +1000
    Re: How difficult is a payroll system? Rich <rich@example.invalid> - 2016-09-01 02:27 +0000
      Re: How difficult is a payroll system? RS Wood <rsw@therandymon.com> - 2016-09-01 02:47 +0000
      Re: How difficult is a payroll system? Sylvia Else <sylvia@not.at.this.address> - 2016-09-01 14:10 +1000
        Re: How difficult is a payroll system? Rich <rich@example.invalid> - 2016-09-01 10:12 +0000
          Re: How difficult is a payroll system? Paul Sture <nospam@sture.ch> - 2016-09-01 21:48 +0200
      Re: How difficult is a payroll system? Sylvia Else <sylvia@not.at.this.address> - 2016-09-01 14:14 +1000
        Re: How difficult is a payroll system? Rich <rich@example.invalid> - 2016-09-01 10:22 +0000
    Re: How difficult is a payroll system? Larry Sheldon <lfsheldon@gmail.com> - 2016-08-31 22:23 -0500
      Re: How difficult is a payroll system? Spiros Bousbouras <spibou@gmail.com> - 2016-09-01 06:44 +0000
        Re: How difficult is a payroll system? Larry Sheldon <lfsheldon@gmail.com> - 2016-09-01 21:09 -0500
      Re: How difficult is a payroll system? Bob Eager <news0006@eager.cx> - 2016-09-01 08:15 +0000
        Re: How difficult is a payroll system? Rich <rich@example.invalid> - 2016-09-01 10:27 +0000
          Re: How difficult is a payroll system? Larry Sheldon <lfsheldon@gmail.com> - 2016-09-01 21:16 -0500
          Re: How difficult is a payroll system? Paul Sture <nospam@sture.ch> - 2016-09-04 22:43 +0200
            Re: How difficult is a payroll system? polygonum <rmoudndgers@vrod.co.uk> - 2016-09-06 07:28 +0100
        Re: How difficult is a payroll system? Paul Sture <nospam@sture.ch> - 2016-09-01 21:18 +0200
          Re: How difficult is a payroll system? Huge <Huge@nowhere.much.invalid> - 2016-09-01 21:23 +0000
            Re: How difficult is a payroll system? Andy Burns <usenet@andyburns.uk> - 2016-09-03 08:17 +0100
              Re: How difficult is a payroll system? Huge <Huge@nowhere.much.invalid> - 2016-09-03 12:17 +0000
                New systems for old (was Re: How difficult is a payroll system?) Larry Sheldon <lfsheldon@gmail.com> - 2016-09-03 22:12 -0500
                  Re: New systems for old (was Re: How difficult is a payroll system?) RS Wood <rsw@therandymon.com> - 2016-09-05 20:00 -0400
                    Re: New systems for old (was Re: How difficult is a payroll system?) Larry Sheldon <lfsheldon@gmail.com> - 2016-09-05 19:36 -0500
                      Re: New systems for old (was Re: How difficult is a payroll system?) Larry Sheldon <lfsheldon@gmail.com> - 2016-09-05 19:42 -0500
              Re: How difficult is a payroll system? Paul Sture <nospam@sture.ch> - 2016-09-04 22:13 +0200
            Re: How difficult is a payroll system? Paul Sture <nospam@sture.ch> - 2016-09-04 22:46 +0200
              Re: How difficult is a payroll system? Huge <Huge@nowhere.much.invalid> - 2016-09-04 21:26 +0000
            Re: How difficult is a payroll system? "Kerr Mudd-John" <admin@127.0.0.1> - 2016-09-18 08:56 +0100
              Re: How difficult is a payroll system? Paul Sture <nospam@sture.ch> - 2016-09-18 10:18 +0200
          Re: How difficult is a payroll system? Larry Sheldon <lfsheldon@gmail.com> - 2016-09-01 21:20 -0500
            Re: How difficult is a payroll system? Paul Sture <nospam@sture.ch> - 2016-09-04 21:41 +0200
        Re: How difficult is a payroll system? Larry Sheldon <lfsheldon@gmail.com> - 2016-09-01 21:11 -0500
      Re: How difficult is a payroll system? Paul Sture <nospam@sture.ch> - 2016-09-04 22:30 +0200
        Re: How difficult is a payroll system? Huge <Huge@nowhere.much.invalid> - 2016-09-04 21:25 +0000

Page 1 of 2  [1] 2  Next page →

#11890 — How difficult is a payroll system?

<http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-echoes-queensland-health/7802944>

I find these stuff-ups hard to fathom. Just how complicated is a payroll 
system? Yes, it deals with lots of transactions, but each one is surely 
straight-forward.

Sylvia.

[toc] | [next] | [standalone]

#11891

Sylvia Else <sylvia@not.at.this.address> wrote:
> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-echoes-queensland-health/7802944>
> 
> I find these stuff-ups hard to fathom. Just how complicated is a
> payroll system?  Yes, it deals with lots of transactions, but each
> one is surely straight-forward.

Oftentimes the problem is that once one looks behind the curtain, what
was a payroll system at one time has sprouted various weed like runners
and now it is payroll plus time keeping plus "big brother" to verify
that workers work what they should, plus it has built in email
messaging, plus built in IM (becase, well, it's too hard to communicate
the normal way, we need it 'embedded' in the system) plus it plots the
Aztec calendar for the next 4000 years, synchronized with the Mayan
calendar for reporting purposes, etc.

I.e., serious feature creep such that no one thing ever gets finished
before two more features that don't belong get bolted on the side until
what was a payroll system is now just Frankenstien's neck.

Couple that with current developers that seem to get hired for these
types of contracts, who assume or produce:

  1) legacy serivces that one calls for data never fail;
  2) legacy services never return error codes;
  3) should either of 1 or 2 occur, simply throw an exception;
  4) process data in large batches;
  5) should either of 1 or 2 happen, anywhere, in the batch of 1,000 or
     10,000 or 100,000 separate items, and an exception gets thrown,
     give up on the whole batch (i.e., a failure on number 1000 out of
     1000 tosses out all the work done for number 1 through number
     999);
  6) perform multiple database updates to plural tables for data where
     all of the updates have to be done or else the data's borked
     without any wrapping SQL transaction (this is usually caused by
     using an object-relational mapping framework because none of the
     devs hired for these projects seem to understand SQL beyond
     "select * from table where X = 10;");
  7) build a task assignment system where a master sets up a job by
     inserting data in a db table, and a separate slave picks it up
     from the same table, and then forget that one has to set things up
     such that the slave should not pick up the job until _after_ the
     master has completed all the necessary updates (literal result of
     of #6 above);
  8) forget that when there are multiple slaves performing "thundering
     herd" attacks on the db for work, that things have to be designed
     such that only one worker picks up any one task (another side
     effect of #6 above)

And you get these outcomes.

[toc] | [prev] | [next] | [standalone]

#11893

On 2016-09-01, Rich <rich@example.invalid> wrote:
> Sylvia Else <sylvia@not.at.this.address> wrote:
>> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-echoes-queensland-health/7802944>
>> 
>> I find these stuff-ups hard to fathom. Just how complicated is a
>> payroll system?  Yes, it deals with lots of transactions, but each
>> one is surely straight-forward.
>
> Oftentimes the problem is that once one looks behind the curtain, what
> was a payroll system at one time has sprouted various weed like runners
> and now it is payroll plus time keeping plus "big brother" to verify
> that workers work what they should, plus it has built in email
> messaging, plus built in IM (becase, well, it's too hard to communicate
> the normal way, we need it 'embedded' in the system) plus it plots the
> Aztec calendar for the next 4000 years, synchronized with the Mayan
> calendar for reporting purposes, etc.

Some of the complexity is likely not their fault: keeping up with
ever-changing tax regulations may have something to do with it.  Worse,
change the taxes 20 times in 20 years and you'll have a progression of staff
working on the code over time: hope you commented and stayed organized!

[toc] | [prev] | [next] | [standalone]

#11896

On 1/09/2016 12:27 PM, Rich wrote:
> Sylvia Else <sylvia@not.at.this.address> wrote:
>> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-echoes-queensland-health/7802944>
>>
>> I find these stuff-ups hard to fathom. Just how complicated is a
>> payroll system?  Yes, it deals with lots of transactions, but each
>> one is surely straight-forward.
>
> Oftentimes the problem is that once one looks behind the curtain, what
> was a payroll system at one time has sprouted various weed like runners
> and now it is payroll plus time keeping plus "big brother" to verify
> that workers work what they should, plus it has built in email
> messaging, plus built in IM (becase, well, it's too hard to communicate
> the normal way, we need it 'embedded' in the system) plus it plots the
> Aztec calendar for the next 4000 years, synchronized with the Mayan
> calendar for reporting purposes, etc.
>
> I.e., serious feature creep such that no one thing ever gets finished
> before two more features that don't belong get bolted on the side until
> what was a payroll system is now just Frankenstien's neck.
>
> Couple that with current developers that seem to get hired for these
> types of contracts, who assume or produce:
>
>    1) legacy serivces that one calls for data never fail;
>    2) legacy services never return error codes;
>    3) should either of 1 or 2 occur, simply throw an exception;
>    4) process data in large batches;
>    5) should either of 1 or 2 happen, anywhere, in the batch of 1,000 or
>       10,000 or 100,000 separate items, and an exception gets thrown,
>       give up on the whole batch (i.e., a failure on number 1000 out of
>       1000 tosses out all the work done for number 1 through number
>       999);
>    6) perform multiple database updates to plural tables for data where
>       all of the updates have to be done or else the data's borked
>       without any wrapping SQL transaction (this is usually caused by
>       using an object-relational mapping framework because none of the
>       devs hired for these projects seem to understand SQL beyond
>       "select * from table where X = 10;");
>    7) build a task assignment system where a master sets up a job by
>       inserting data in a db table, and a separate slave picks it up
>       from the same table, and then forget that one has to set things up
>       such that the slave should not pick up the job until _after_ the
>       master has completed all the necessary updates (literal result of
>       of #6 above);
>    8) forget that when there are multiple slaves performing "thundering
>       herd" attacks on the db for work, that things have to be designed
>       such that only one worker picks up any one task (another side
>       effect of #6 above)
>
> And you get these outcomes.
>

Granted that over time systems can turn into unmaintainable labyrinths 
of code, but this was a new system.

Sylvia.

[toc] | [prev] | [next] | [standalone]

#11901

Sylvia Else <sylvia@not.at.this.address> wrote:
> On 1/09/2016 12:27 PM, Rich wrote:
>> Sylvia Else <sylvia@not.at.this.address> wrote:
>>> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-echoes-queensland-health/7802944>
>>>
>>> I find these stuff-ups hard to fathom. Just how complicated is a
>>> payroll system?  Yes, it deals with lots of transactions, but each
>>> one is surely straight-forward.
>>
>> Oftentimes the problem is that once one looks behind the curtain, what
>> was a payroll system at one time has sprouted various weed like runners
>> and now it is payroll plus time keeping plus "big brother" to verify
>> that workers work what they should, plus it has built in email
>> messaging, plus built in IM (becase, well, it's too hard to communicate
>> the normal way, we need it 'embedded' in the system) plus it plots the
>> Aztec calendar for the next 4000 years, synchronized with the Mayan
>> calendar for reporting purposes, etc.
>>
>> I.e., serious feature creep such that no one thing ever gets finished
>> before two more features that don't belong get bolted on the side until
>> what was a payroll system is now just Frankenstien's neck.
>>
>> Couple that with current developers that seem to get hired for these
>> types of contracts, who assume or produce:
>>
>> ... [long list snipped - see prior article for list]
>>
>> And you get these outcomes.
> 
> Granted that over time systems can turn into unmaintainable labyrinths 
> of code, but this was a new system.

Part of my point is/was that for these sorts of systems, the govt. 
folks who spec. them out often spec. out an unmaintainable labyrinth
at the outset.  That combined with what seems to be the operating level
of the typical coder employed on these projects and you get these
messes on brand new systems.

The current metaphor among those who work on these type systems seems
to be to ingore any potential source of failure that can be easily
anticipated.  I.e., don't bother to try to anticipate how/why this code
might fail and code defensively, just write code that *only* ever
expects happy path data and let it fail/throw an exception when
something goes wrong and then clean up the resulting mess later.  This
'mindset' in C would mean never checking for NULL from any library
calls that return NULL to mean "call failed" and instead just
dereferencing the pointer returned and watching the segfault happen
over and over again as each failure path (many of which stick out like
a sore thumb from reading the code alone) is discovered in production
by all the segfaulting.

The previously posted list of 'issues' are all from a brand new system.

[toc] | [prev] | [next] | [standalone]

#11905

On 2016-09-01, Rich <rich@example.invalid> wrote:
>
> The previously posted list of 'issues' are all from a brand new system.

The Swiss Railways recently reported a new system to be a 19 million
Franc flop.  

I'm sure there's a lot more to it than the few details reported in
the media, but one problem area was in linking the actual running times
of trains into the payroll, such that extra hours are credited to staff
manning a train which runs late.  Apparently staff were seeing things
like holiday entitlements disappear because negative hours had come
from somewhere.

Outsourced to Accenture Ireland, partly developed in Asia. 

-- 
It was untidy, so got unplugged.
It was unplugged, so got thrown away.

[toc] | [prev] | [next] | [standalone]

#11897

On 1/09/2016 12:27 PM, Rich wrote:

>    6) perform multiple database updates to plural tables for data where
>       all of the updates have to be done or else the data's borked
>       without any wrapping SQL transaction (this is usually caused by
>       using an object-relational mapping framework because none of the
>       devs hired for these projects seem to understand SQL beyond
>       "select * from table where X = 10;");

A related horror is the two-phase commit on multiple databases.

I spent a lot of time with a systems-architect before I could convince 
him that a two-phase commit has failure modes, and cannot be regarded as 
100% reliable.

Indeed, it wasn't obvious that I had convinced him, because he was the 
kind of person who won't admit that they've changed their previous view, 
but would quietly change his tune later.

Sylvia.

[toc] | [prev] | [next] | [standalone]

#11902

Sylvia Else <sylvia@not.at.this.address> wrote:
> On 1/09/2016 12:27 PM, Rich wrote:
> 
>>    6) perform multiple database updates to plural tables for data where
>>       all of the updates have to be done or else the data's borked
>>       without any wrapping SQL transaction (this is usually caused by
>>       using an object-relational mapping framework because none of the
>>       devs hired for these projects seem to understand SQL beyond
>>       "select * from table where X = 10;");
> 
> A related horror is the two-phase commit on multiple databases.
> 
> I spent a lot of time with a systems-architect before I could convince 
> him that a two-phase commit has failure modes, and cannot be regarded as 
> 100% reliable.

Ah, yes, the "magic" two-phase commit that fixes all one's database
replication woes (until one learns enough to realize the fact you
state above).

But even a single DB and a single commit has failure modes (just
usually not directly with the actual DB update itself).  The DB server
could go down, the network connection from the client to the server
could go down, the network disk storage underlying the DB could
disappear (yes, the hardware architects were dumb enough to use network
storage as the backing store for the DB itself).

And unless the code pushing out the queries to the DB's designed to
accomodate possible failures from the DB, things again break when
'other' stuff happens.

I have a couple suspisions for 'why's on these concepts.  One is that
the ones building the code are not the top-notch devs.  Another is that
the ones building the code are all young enough, and computer hardware
has in general become reliable enough, that they just don't have the
built in understanding of things failing, because in many cases they've
never, ever, seen anything fail.  The network always works, the DB
always replies, the NFS always returns the data I put on it....

> Indeed, it wasn't obvious that I had convinced him, because he was
> the kind of person who won't admit that they've changed their
> previous view, but would quietly change his tune later.

Ah, yes, don't admit being wrong because then that detracts from the
"I'm smarter than you - what do you think you know about it" attitude. 
Yeah, I know those types.

[toc] | [prev] | [next] | [standalone]

#11895

On 8/31/2016 21:04, Sylvia Else wrote:
> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-echoes-queensland-health/7802944>
>
>
> I find these stuff-ups hard to fathom. Just how complicated is a payroll
> system? Yes, it deals with lots of transactions, but each one is surely
> straight-forward.

They ARE straight-forward.

Unless you have to provide for over-time rules, union rules, state laws 
and rules. state tax laws and rules, FSMCA rules and laws, FRA rules and 
laws, OSHA rules and laws, differing plant rules, customs, practices, 
and traditions and the rest of a forbidding pile of minutia.  Did I 
mention GAAP?


-- 
quis custodiet ipsos custodes?
-- Juvenal

[toc] | [prev] | [next] | [standalone]

#11899

On Wed, 31 Aug 2016 22:23:03 -0500
Larry Sheldon <lfsheldon@gmail.com> wrote:
> On 8/31/2016 21:04, Sylvia Else wrote:
> > <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-echoes-queensland-health/7802944>
> >
> >
> > I find these stuff-ups hard to fathom. Just how complicated is a payroll
> > system? Yes, it deals with lots of transactions, but each one is surely
> > straight-forward.
> 
> They ARE straight-forward.
> 
> Unless you have to provide for over-time rules, union rules, state laws 
> and rules. state tax laws and rules, FSMCA rules and laws, FRA rules and 
> laws, OSHA rules and laws, differing plant rules, customs, practices, 
> and traditions and the rest of a forbidding pile of minutia.  Did I 
> mention GAAP?

FSMCA = Flying Spaghetti Monster Certificate Authority  ?

[toc] | [prev] | [next] | [standalone]

#11909

On 9/1/2016 01:44, Spiros Bousbouras wrote:
> On Wed, 31 Aug 2016 22:23:03 -0500
> Larry Sheldon <lfsheldon@gmail.com> wrote:
>> On 8/31/2016 21:04, Sylvia Else wrote:
>>> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-echoes-queensland-health/7802944>
>>>
>>>
>>> I find these stuff-ups hard to fathom. Just how complicated is a payroll
>>> system? Yes, it deals with lots of transactions, but each one is surely
>>> straight-forward.
>>
>> They ARE straight-forward.
>>
>> Unless you have to provide for over-time rules, union rules, state laws
>> and rules. state tax laws and rules, FSMCA rules and laws, FRA rules and
>> laws, OSHA rules and laws, differing plant rules, customs, practices,
>> and traditions and the rest of a forbidding pile of minutia.  Did I
>> mention GAAP?
>
> FSMCA = Flying Spaghetti Monster Certificate Authority  ?

Close.  Dunno if it was old age, fat fingers or simple typo for FMCSA.
-- 
quis custodiet ipsos custodes?
-- Juvenal

[toc] | [prev] | [next] | [standalone]

#11900

On Wed, 31 Aug 2016 22:23:03 -0500, Larry Sheldon wrote:

> On 8/31/2016 21:04, Sylvia Else wrote:
>> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-
echoes-queensland-health/7802944>
>>
>>
>> I find these stuff-ups hard to fathom. Just how complicated is a
>> payroll system? Yes, it deals with lots of transactions, but each one
>> is surely straight-forward.
> 
> They ARE straight-forward.
> 
> Unless you have to provide for over-time rules, union rules, state laws
> and rules. state tax laws and rules, FSMCA rules and laws, FRA rules and
> laws, OSHA rules and laws, differing plant rules, customs, practices,
> and traditions and the rest of a forbidding pile of minutia.  Did I
> mention GAAP?

And constant changes from the government.



-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#11903

Bob Eager <news0006@eager.cx> wrote:
> On Wed, 31 Aug 2016 22:23:03 -0500, Larry Sheldon wrote:
> 
>> On 8/31/2016 21:04, Sylvia Else wrote:
>>> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-
> echoes-queensland-health/7802944>
>>>
>>>
>>> I find these stuff-ups hard to fathom. Just how complicated is a
>>> payroll system? Yes, it deals with lots of transactions, but each one
>>> is surely straight-forward.
>> 
>> They ARE straight-forward.
>> 
>> Unless you have to provide for over-time rules, union rules, state laws
>> and rules. state tax laws and rules, FSMCA rules and laws, FRA rules and
>> laws, OSHA rules and laws, differing plant rules, customs, practices,
>> and traditions and the rest of a forbidding pile of minutia.  Did I
>> mention GAAP?
> 
> And constant changes from the government.

This one is often a big driver of the problem.  The typical
politician/burecrat creating the constantly changing network of
overlapping rules also drive the "automate the things" process as well,
without understanding that their constant stream of rules changes mean
a constant stream of software changes.  Apparently they don't quite
understand the cause and effect that occurs there.

And couple that with the fact that very seldom does an existing rule
get removed.  It stays on, grandfathered for certian specific phases of
the moon and such, further adding to the overall complexity.

[toc] | [prev] | [next] | [standalone]

#11911

On 9/1/2016 05:27, Rich wrote:
> Bob Eager <news0006@eager.cx> wrote:
>> On Wed, 31 Aug 2016 22:23:03 -0500, Larry Sheldon wrote:
>>
>>> On 8/31/2016 21:04, Sylvia Else wrote:
>>>> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-
>> echoes-queensland-health/7802944>
>>>>
>>>>
>>>> I find these stuff-ups hard to fathom. Just how complicated is a
>>>> payroll system? Yes, it deals with lots of transactions, but each one
>>>> is surely straight-forward.
>>>
>>> They ARE straight-forward.
>>>
>>> Unless you have to provide for over-time rules, union rules, state laws
>>> and rules. state tax laws and rules, FSMCA rules and laws, FRA rules and
>>> laws, OSHA rules and laws, differing plant rules, customs, practices,
>>> and traditions and the rest of a forbidding pile of minutia.  Did I
>>> mention GAAP?
>>
>> And constant changes from the government.
>
> This one is often a big driver of the problem.  The typical
> politician/burecrat creating the constantly changing network of
> overlapping rules also drive the "automate the things" process as well,
> without understanding that their constant stream of rules changes mean
> a constant stream of software changes.  Apparently they don't quite
> understand the cause and effect that occurs there.
>
> And couple that with the fact that very seldom does an existing rule
> get removed.  It stays on, grandfathered for certian specific phases of
> the moon and such, further adding to the overall complexity.

This last 'graf operates as a multiplier from the needed myriad 
additions of "If payroll date is equal to or greater than...." forks at 
each microcosm of code.

-- 
quis custodiet ipsos custodes?
-- Juvenal

[toc] | [prev] | [next] | [standalone]

#11943

On 2016-09-01, Rich <rich@example.invalid> wrote:
> Bob Eager <news0006@eager.cx> wrote:
>> On Wed, 31 Aug 2016 22:23:03 -0500, Larry Sheldon wrote:
>> 
>>> On 8/31/2016 21:04, Sylvia Else wrote:
>>>> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-
>> echoes-queensland-health/7802944>
>>>>
>>>>
>>>> I find these stuff-ups hard to fathom. Just how complicated is a
>>>> payroll system? Yes, it deals with lots of transactions, but each one
>>>> is surely straight-forward.
>>> 
>>> They ARE straight-forward.
>>> 
>>> Unless you have to provide for over-time rules, union rules, state laws
>>> and rules. state tax laws and rules, FSMCA rules and laws, FRA rules and
>>> laws, OSHA rules and laws, differing plant rules, customs, practices,
>>> and traditions and the rest of a forbidding pile of minutia.  Did I
>>> mention GAAP?
>> 
>> And constant changes from the government.
>
> This one is often a big driver of the problem.  The typical
> politician/burecrat creating the constantly changing network of
> overlapping rules also drive the "automate the things" process as well,
> without understanding that their constant stream of rules changes mean
> a constant stream of software changes.  Apparently they don't quite
> understand the cause and effect that occurs there.

Going back to the days when most small companies would do payroll
manually, there were whole books full of tables.  The production of
those probably required a whole army of government employees, who needed
to be kept busy with the next round.

> And couple that with the fact that very seldom does an existing rule
> get removed.  It stays on, grandfathered for certian specific phases of
> the moon and such, further adding to the overall complexity.

The UK's social contributions had special categories for dockers and
seamen.  We didn't have any customers who employed those folks, so
didn't explore that, but just one sale into that sector could have
caused us an awful lot of work.

-- 
It was untidy, so got unplugged.
It was unplugged, so got thrown away.

[toc] | [prev] | [next] | [standalone]

#11953

On 04/09/2016 21:43, Paul Sture wrote:
> The UK's social contributions had special categories for dockers and
> seamen.  We didn't have any customers who employed those folks, so
> didn't explore that, but just one sale into that sector could have
> caused us an awful lot of work.

COBOL on ICL computers even had a special data type for, IIRC, miners.

-- 
Rod

[toc] | [prev] | [next] | [standalone]

#11904

On 2016-09-01, Bob Eager <news0006@eager.cx> wrote:
> On Wed, 31 Aug 2016 22:23:03 -0500, Larry Sheldon wrote:
>
>> On 8/31/2016 21:04, Sylvia Else wrote:
>>> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-
> echoes-queensland-health/7802944>
>>>
>>>
>>> I find these stuff-ups hard to fathom. Just how complicated is a
>>> payroll system? Yes, it deals with lots of transactions, but each one
>>> is surely straight-forward.
>> 
>> They ARE straight-forward.
>> 
>> Unless you have to provide for over-time rules, union rules, state laws
>> and rules. state tax laws and rules, FSMCA rules and laws, FRA rules and
>> laws, OSHA rules and laws, differing plant rules, customs, practices,
>> and traditions and the rest of a forbidding pile of minutia.  Did I
>> mention GAAP?
>
> And constant changes from the government.
>

Having worked on payroll, the yearly changes to tax and social
contributions seemed to be designed to break existing systems.  It
didn't matter how well you had parameterised your payroll system to
minimise the impact of regulatory changes, the government would find a
way that forced you to change your code.

-- 
It was untidy, so got unplugged.
It was unplugged, so got thrown away.

[toc] | [prev] | [next] | [standalone]

#11906

On 2016-09-01, Paul Sture <nospam@sture.ch> wrote:
> On 2016-09-01, Bob Eager <news0006@eager.cx> wrote:
>> On Wed, 31 Aug 2016 22:23:03 -0500, Larry Sheldon wrote:
>>
>>> On 8/31/2016 21:04, Sylvia Else wrote:
>>>> <http://www.abc.net.au/news/2016-09-01/canada-ibm-payroll-debacle-
>> echoes-queensland-health/7802944>
>>>>
>>>>
>>>> I find these stuff-ups hard to fathom. Just how complicated is a
>>>> payroll system? Yes, it deals with lots of transactions, but each one
>>>> is surely straight-forward.
>>> 
>>> They ARE straight-forward.
>>> 
>>> Unless you have to provide for over-time rules, union rules, state laws
>>> and rules. state tax laws and rules, FSMCA rules and laws, FRA rules and
>>> laws, OSHA rules and laws, differing plant rules, customs, practices,
>>> and traditions and the rest of a forbidding pile of minutia.  Did I
>>> mention GAAP?
>>
>> And constant changes from the government.
>>
>
> Having worked on payroll, the yearly changes to tax and social
> contributions seemed to be designed to break existing systems.  It
> didn't matter how well you had parameterised your payroll system to
> minimise the impact of regulatory changes, the government would find a
> way that forced you to change your code.

Having worked on payroll, I completely agree.

I suspect many (most?) employers have solved this by outsourcing it.

-- 
Today is Prickle-Prickle, the 25th day of Bureaucracy in the YOLD 3182
                  I don't have an attitude problem.
    If you have a problem with my attitude, that's your problem.

[toc] | [prev] | [next] | [standalone]

#11914

Huge wrote:

> Paul Sture wrote:
>
>> Having worked on payroll, the yearly changes to tax and social
>> contributions seemed to be designed to break existing systems.  It
>> didn't matter how well you had parameterised your payroll system to
>> minimise the impact of regulatory changes, the government would find a
>> way that forced you to change your code.
>
> Having worked on payroll, I completely agree.

Ditto (and I dare say it's got worse in the past 25 years).

Accounts packages can run unchanged for years, with just the occasional 
tweak to tax rates, payroll tends to need program changes for edge cases 
as well as tax rate/threshold changes.

[toc] | [prev] | [next] | [standalone]

#11915

On 2016-09-03, Andy Burns <usenet@andyburns.uk> wrote:
> Huge wrote:
>
>> Paul Sture wrote:
>>
>>> Having worked on payroll, the yearly changes to tax and social
>>> contributions seemed to be designed to break existing systems.  It
>>> didn't matter how well you had parameterised your payroll system to
>>> minimise the impact of regulatory changes, the government would find a
>>> way that forced you to change your code.
>>
>> Having worked on payroll, I completely agree.
>
> Ditto (and I dare say it's got worse in the past 25 years).
>
> Accounts packages can run unchanged for years, with just the occasional 
> tweak to tax rates, payroll tends to need program changes for edge cases 
> as well as tax rate/threshold changes.

And when we parallel ran the new system (written in [spit]RPG2), the numbers
were different from the old one.

The old one was wrong.


-- 
Today is Sweetmorn, the 27th day of Bureaucracy in the YOLD 3182
                  I don't have an attitude problem.
    If you have a problem with my attitude, that's your problem.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.misc

csiph-web