Odd doings in California

On Fri, 05 Sep 2008 08:18:19 -0500, Robert <no@e.mail> wrote:

>On Fri, 5 Sep 2008 07:13:15 -0500, "Michael Mattias" <mmattias@talsystems.com> wrote:
>
>>"donald tees" <donaldtees@execulink.com> wrote in message
>>news:PpKdnR5-U_d5vVzVnZ2dnUVZ_u6dnZ2d@golden.net...
>>> docdwarf@panix.com wrote:
>>>> Then there are the 'gamings' of the system... is an employee's on-call
>>>> rate the same as their new minimum-wage salary? [...]
>>>> 1915 program.....
>>
>>So much concern about these details that nobody has identified the
>>fundamental problem here:
>>
>>Government is too big and simply has to pay too many people.
>
>Every industry goes through a consolidation phase in which stronger states acquire weaker
>ones. Thus, governmental efficiency improves through elimination of redundant employees
>and products.
>
>Texas governor Rick Perry announced the acquisition of California will be final 4Q 2008,
>subject to FTC and taxpayer approval. He cited synergies between their scenery and his
>state's capitalization. In a similar vein, New York has begun preliminary talks with
>Florida.
>
>To defend against predatory acquisition (hostile takeover), northeastern states will be
>forming the New England Union in 2010. The sole holdout is maverick New Hampshire, which
>is pursuing a joint venture with Montana. Industry analysts think such a partnership is
>unlikely. Sensing vulnerability, Canada will soon open an embassy in Nashua. A Canadian
>spokesman said, "It's a natural, given their high tech and our cheap labor."
>
>Wyoming filed Chapter 7 bankruptcy last month.

I doubt that. Chapter 7 is for personal bankruptcy and is total
bankruptcy which stays on your credit report for 10 years. Chapter 13
Bankruptcy, more like a payment plan, stays on your credit report for
7 years. Chapter 11 is more like a reorganization and is used by
corporations and sole proprietorships.

Municipalities, i.e. cities and states, could file bankruptcy under
Chapter 9 only.

Regards,
////
(o o)
-oOO--(_)--OOo-

"I'm addicted to placebos. I'd give them up, but it wouldn' make
any difference."
-- Steven Wright
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

Why use contractors? There must be people maintaining the system.

Select workers for the task - 1 week
Analysis - 1 week because they know the system
Set up test environment - 1 day, because it already exists
Development - change programs - 2 days
Unit testing (presumably the changed programs - can't be many if the changes
only take 2 days) - 1 week
System & regression testing - 30 days
Production build - 1 day. This is only the 10,000th time they've done this.
Dress rehearsals and spot checks - ??? - no different from any other rate
change scenario
Approvals - 1 week.

Total, 6 weeks.

It looks to me as though the I/T people, particularly management, just don't
want to do it because of the messes that will result - not programming
messes, but personal, institutional, and political.

PL

Robert <no@e.mail> wrote in message
news:gnd1c4trsc8kgqg6po1vrnj5ffvtuussen@4ax.com...
> On Thu, 4 Sep 2008 23:17:59 -0500, "tlmfru" <lacey@mts.net> wrote:
>
> >Chiang has said it can't be done. He isn't refusing, but says it's
> >impossible "because of the age of the state's payroll system which is
based
> >on Cobol, it would take at least six months to reconfigure the system to
> >send out those new minimum-wage checks".
>
> Recruit, hire and train contractors: 30 days
> Analysis: 30 days
> Setup test environment: 30 days
> Development -- change programs: 2 days
> Unit testing: 28 days
> System testing: 30 days
> Regression testing: 14 days
> Production build and deployment: 7 days
> Dress rehersal and spot checks: 14 days
> Obtain approvals: 7 days
>
> Total 6.5 months
>
>

On Sep 6, 2:39*am, "HeyBub" <hey...@NOSPAMgmail.com> wrote:
> Robert wrote:
> > On Thu, 4 Sep 2008 23:17:59 -0500, "tlmfru" <la...@mts.net> wrote:
>
> >> Chiang has said it can't be done. *He isn't refusing, but says it's
> >> impossible "because of the age of the state's payroll system which
> >> is based on Cobol, it would take at least six months to reconfigure
> >> the system to send out those new minimum-wage checks".
>
> > Recruit, hire and train contractors: 30 days
> > Analysis: 30 days
> > Setup test environment: 30 days
> > Development -- change programs: 2 days
> > Unit testing: 28 days
> > System testing: 30 days
> > Regression testing: 14 days
> > Production build and deployment: 7 days
> > Dress rehersal and spot checks: 14 days
> > Obtain approvals: *7 days
>
> > Total 6.5 months
>
> Oh bother!
>
> There's a field for hourly rate for every employee and virtually every
> employee has had their rate changed once upon a time.
>
> So, call up an employee record. Change the hourly rate to the minimum wage.
> Punch the "save" button.
>
> At 30 seconds for each employee, and using 50 trained monkeys, the task
> could be done in less than a week.

While I may be further away than most here, I think that the problem
is not that at all. It is probably quite easy to change the rates.

The requirement is, AFAIK, that should the rates be reduced then this
may be later overturned, by an employment court eg, and the shortfall
over the period will need to be paid to the employees (possibly plus
interest). The system will need to keep _two_ sets of data. One for
the pay that they would have received and another for the minimum pay
that they did receive.

It may be that they could clone the system and modify the rates on one
of them. They would still need a great deal of work for the input
data to be gathered and selectively processed by the 'shadow'.

In article <2m9wk.12276$vn7.5678@flpi147.ffdc.sbc.com>,
Michael Mattias <mmattias@talsystems.com> wrote:
>"donald tees" <donaldtees@execulink.com> wrote in message
>news:PpKdnR5-U_d5vVzVnZ2dnUVZ_u6dnZ2d@golden.net...
>> docdwarf@panix.com wrote:
>>> Then there are the 'gamings' of the system... is an employee's on-call
>>> rate the same as their new minimum-wage salary? [...]
>>> 1915 program.....
>
>So much concern about these details that nobody has identified the
>fundamental problem here:
>
>Government is too big and simply has to pay too many people.

Too big/too many as compared to a size determined by what method?

DD

In article <3if2c4pnfobqrjh02k6pjbk8o4hcb7r4dl@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Fri, 5 Sep 2008 09:58:15 +0000 (UTC), docdwarf@panix.com () wrote:
>
>>Now... the question of 'the extraction of business rules' and 'the
>>extraction of logic rules' is where it gets sticky. Take the example of
>>an insurance-claims system. It seems logical and businesslike to allow
>>for a claim to be made for the treatment of uterine infections... BUT NOT
>>if the policy's group doesn't have a rider to cover such treatments...
>>
>>... then it's OK... BUT NOT IF the claimant is a male...
>
>Now why would a computer program need to disallow uterine treatments
>for males?

I don't recall seeing where it was stated that a computer program was
allowing or disallowing the situation quoted above; the situation was
given in order to show where things get sticky in the question of 'the
extraction of business rules' and 'the extraction of logic rules'.

>
>I suppose fraud analysis can be done within the standard claim
>programs, but is that a good design?

That would depend on the criteria one uses for good, I would say... how
much work does one want the machine to do versus how much work does one
want a human being to do being one of the points of measure.

For example... in the case given above, males - usually - do not have
female reproductive organs and, as such, usually require little treatment
for them. A design decision is made... if such a situation is encountered
is it to be assumed to be correct - and passed along for payment - or
considered to be in error, and sent to a supervisor/verifier/inspectrix
for examination and over-ride?

As I was taught design... tests for the most common cases are first and
the less common cases follow; this saves on both machine time and human
time. For example... since there aren't too many folks around who were
born before 1850 (Gregorian calendar) it might be a Good Idea to have a
data-entry system for driver's licenses throw an 'Invalid Date' if this is
entered into a Date of Birth field.

The program is coded to disallow this as a transaction (without
appropriate supervisory over-ride)... and this would seem to be good
design as it would, most frequently, prevent a license being issued with a
typo that would require a licensee to go through the issuing process again
due to a simple typo.

It'd make it a bit more difficult for folks older than one hundred and
fifty-seven years to get *their* licenses dealt with... but
back-of-the-envelope calculations could show there is an acceptable
cost/benefit ratio.

Names, on the other hand, are a whole 'nother kettle of fish... is 'John
Simth' a typo? Is 'Pat Yerbottom' male or female? Is 'Talula Does The
Hula From Hawaii' legal? These questions are, I would say, qualitatively
different than 'Should a request to issue a driver's license to someone
born in 1850 be permitted without further question?'

These are things that Business Analysts used to... analyse.

DD

In article <SPOdnTAMp_QP2VzVnZ2dnUVZ_j-dnZ2d@earthlink.com>,
HeyBub <heybub@NOSPAMgmail.com> wrote:

[snip]

>So, call up an employee record. Change the hourly rate to the minimum wage.
>Punch the "save" button.
>
>At 30 seconds for each employee, and using 50 trained monkeys, the task
>could be done in less than a week.

.... proving, yet again, H L Mencken's assertion that 'For every complex
problem, there is a solution that is simple, neat and wrong.'

DD

In article <PpKdnR5-U_d5vVzVnZ2dnUVZ_u6dnZ2d@golden.net>,
donald tees <donaldtees@execulink.com> wrote:
>docdwarf@panix.com wrote:
>> In article <gnd1c4trsc8kgqg6po1vrnj5ffvtuussen@4ax.com>,
>> Robert <no@e.mail> wrote:
>>> On Thu, 4 Sep 2008 23:17:59 -0500, "tlmfru" <lacey@mts.net> wrote:
>>>
>>>> Chiang has said it can't be done. He isn't refusing, but says it's
>>>> impossible "because of the age of the state's payroll system which is based
>>>> on Cobol, it would take at least six months to reconfigure the system to
>>>> send out those new minimum-wage checks".
>>> Recruit, hire and train contractors: 30 days
>>> Analysis: 30 days
>>> Setup test environment: 30 days
>>> Development -- change programs: 2 days
>>
>> Not... really. This is Payroll, remember... civil-service payroll, at
>> that, and my own recent, small experience shows that there are intricacies
>> which might be a bit more demanding than a universal MOVE LS-MIN-WAGE TO
>> D431652-EMP-MSTR-PRIM-SAL.
>>
>> For instance... what about savings-plans contributions?

[snip]

>> ... and it goes on... and then there's the little matter of reversing and
>> auditing the changes once the brou-ha-ha is over... *and* maintaining a
>> full Production load while all this is going on. The 'all ya gotta do is'
>> approach is quite Managerial, I'll agree... and it might even be a good
>> thing, in this case, since if God or the Devil or both are in the details
>> then it looks like there's a healthy separation of Church and State.
>>
>
>You missed the 5000 lines of code dealing with specific amounts coming
>out of specific funds ... you know, where 3.75 an hour of Joe's salary
>is allocated to state funding, but 2.25 is federal program 167-A53-z,
>from back in 1915, and 1.50 an hour comes out of capital, because the
>1915 program is still considered new. And that those have to add up
>correctly to the contract amount ... which does not exist, but is still
>set to last years.

Mr Tees, I've tried to answer a couple of other posts on this matter...
but I believe that I am seeing evidence of who, exactly, has spent much
time dealing with actual Civil Service pay systems and who hasn't.

DD

Rick Smith wrote:
> <docdwarf@panix.com> wrote in message news:g9sda3$173$1@reader1.panix.com...
>> In article
> <9bb64803-91f2-4cb0-bb67-bed24bec577e@v13g2000pro.googlegroups.com>,
>> Richard <riplin@azonic.co.nz> wrote:
>>
>> [snip]
>>
>>> While I may be further away than most here, I think that the problem
>>> is not that at all. It is probably quite easy to change the rates.
>> Mr Plinston, as both Mr Tees and I have tried to point out... paying Civil
>> Service employees is not only a matter of rates.
>
> The particular situation in California, as I recall, falls under
> the Governor's emergency powers and, as such, the solution
> depends a great deal upon what may be suspended. Thus,
> Mr Dwarf, it may not be as complex as regular payroll.
>
>
Then why use a computer? If it is that simple, just withdraw a few
million from a bank account, and start handing it out.

Donald

In article <l7ednQVqPuS6cFzVnZ2dnUVZ_orinZ2d@posted.mid-floridainternet>,
Rick Smith <ricksmith@mfi.net> wrote:
>
><docdwarf@panix.com> wrote in message news:g9smpd$67m$1@reader1.panix.com...
>> In article <ho6dnds1GsRlS1zVnZ2dnUVZ_o7inZ2d@posted.mid-floridainternet>,
>> Rick Smith <ricksmith@mfi.net> wrote:
>> >
>> ><docdwarf@panix.com> wrote in message
>news:g9sda3$173$1@reader1.panix.com...
>> >> In article
>> ><9bb64803-91f2-4cb0-bb67-bed24bec577e@v13g2000pro.googlegroups.com>,
>> >> Richard <riplin@azonic.co.nz> wrote:
>> >>
>> >> [snip]
>> >>
>> >> >While I may be further away than most here, I think that the problem
>> >> >is not that at all. It is probably quite easy to change the rates.
>> >>
>> >> Mr Plinston, as both Mr Tees and I have tried to point out... paying
>Civil
>> >> Service employees is not only a matter of rates.
>> >
>> >The particular situation in California, as I recall, falls under
>> >the Governor's emergency powers and, as such, the solution
>> >depends a great deal upon what may be suspended. Thus,
>> >Mr Dwarf, it may not be as complex as regular payroll.
>
>[snip]
>
>> In the admission that 'it may not be as complex as regular payroll' might
>> lie the situation of 'it is less complex than regular payroll', 'it is
>> more complex than regular payroll', 'it may not be at the moment but might
>> when the next set of quarterly financials are generated'...
>
>While I admit, Mr Dwarf, to being unfamiliar with all forms
>of logic. A form with which I am familiar would preclude
>any other than what I wrote.
>
>Given that R is the complexity of regular payroll measured
>by the number of rules and that S is the complexity of the
>number of rules suspended; then R minus S 'may not be
>as complex as' R, or ((R - S) <= R), seems to be the only
>logical conclusion.

Consider, Mr Smith, that persons earning only (salary) or greater are
eligible )by law ) for participation in (program). Several thousand
people, due to a decrease in salary, are suddenly no longer eligible to
participate and their previous participations are to be changed to a
different status.

I would say that the change in salary, mandating this 'waterfall' of other
changes, makes things more complex, not less.

In other words... Mr Smith, you seem to be stating that the change in
salary is represented as the subtracting of S ( ' - S'). This is where we
differ, perhaps, in that given a system as complex as a Civil Service
payroll system a change in salary might well have results that are other
than simply minus or plus... the delta's the thing.

DD

In article <dJGdnQHgBPrvmF_VnZ2dnUVZ_qninZ2d@posted.mid-floridainternet>,
Rick Smith <ricksmith@mfi.net> wrote:
>
><docdwarf@panix.com> wrote in message news:g9smpd$67m$1@reader1.panix.com...
>
>[snip]
>
>> ... in short, Mr Smith, this 'may be' encounters a variety of
>> possibilities and until such time as the probability of outcome is
>> determined it might - given that one is dealing with peoples' paychecks,
>> often a rather emotion-laden issue - be best to dismiss any 'all ya gotta
>> do is' with a politician's 'that's an interesting proposal... get me some
>> resource estimates on that from three Approved Vendors and we'll discuss
>> them at the next session.'
>
>I would be remiss if I fail to mention that, for a payroll system.
>'all ya gotta do is' follow the clerical paradigm; that is, do in
>the program whatever a clerk would do to get the correct results.

It would be likewise remiss, Mr Smith, to fail to mention that a computer
system should make it necessary for a clerk to do fewer things to get the
correct results. If 'doing things' requires an expenditure of energy and,
by definition, an expenditure of energy is work... then let it be recalled
that Machines Work, People Think.

DD