Wednesday, October 23, 2013

Affordable Healthcare Act computer system FUBR

Needless correction on Mondays blog and I was told to not worry about it but I needed an excuse to bring up the auditorium once again.

The grant money is not from the gov but from private interests. With that said I hope they have looked into public money and grants as I know there is a ton out there (perhaps 25%??).

I needed an excuse to Auditorize the blog because I was playing around with another photo.

 --------------------------------
Affordable Healthcare Act

Being a computer programmer for Health Services I have firsthand knowledge of the workings of government computer systems and how they are created.  Talking to fellow workers yesterday we were all in agreement that the REAL surprise would have been if the AHA had gone up smoothly. 

Seriously.  I've been in the middle of some major system development and it's a joke on how things get done.  Here is what I believe happened.

The idea comes down from above - we need this system.  At that point they talk to contracting companies who have a bunch of young smart and slick dudes with all the latest tools for system development but no real knowledge of government computer systems which are different then private industry computer systems.

Why are they different?  Because private industry systems are stable for the most part. They always have the latest in technology and upgrades.  Government systems are the trailing edge of technology and put together by roaming teams of other contractors that create their little box of code that works great and then the lower paid government programmers take over maintenance and start to put band-aids and quick fixes to update and make the programs run.

After a while, the systems run perfectly BUT, are like a 100 year old house that add one room every year but with a new style of equipment and builders with vast degrees of expertise. The goal is to make it run as fast and as cheap as possible, not to have perfect code.   It's a well built house of cards.

SO - now the contracting company starts to REALLY nail down what is needed and where the data goes and comes from and how it all fits together.  They are constantly told by the government programmers "you can't do that, it won't work, that pipe will not go through that wall without leaking" but they don't listen, of course it will they say. 

Meanwhile the specifications keep changing as new ideas come in and they realize that the government programmers might be right BUT, they can deal with it later because NOW, it would mean they, personally, were wrong and that will look bad on their resume' next year.  Just because the gov programmers have taken care of the systems for the last 15 years does not mean they know the NEW way to program. 

After a while things are looking better until contracting staff starts to turn over because the young dudes like to move around and health care is so boring and fucked up. This will look bad on their resume'.   So they hire new slick dudes who need at least 6 months to understand the ever changing system.

MEANWHILE - the middle management who are in charge and used to be very good programmers  believe they know the user end and what it needs although they have never had any training on THAT side but, they were promoted to this job so they MUST be experts.

There are troubles in Washington and specifications are now changing daily and all of a sudden the drop dead date is here and BAM!!!  Nothing works.  The contractor round pipes are not talking to the government square pipes and 20 year old COBOL systems are not talking to 1 year old JAVA, C, C++, PHP languages and all hell breaks loose.  

THOSE DAMN LOW PAID GOVERNMENT PROGRAMMERS WITH THEIR TRAILING EDGE TECHNOLOGY ARE THE PROBLEM.

HOWEVER - another point of view has come in which I also agree with

Not sure if I concur.  My company runs some pretty old software.  I do believe that the biggest problem with government computing is the ever changing landscape of requirements.  Private companies do have to react to changes in government regulations but that is only a small subset of what changes that federal and state government programmers have to enact.  Plus because all requirements are still being defined as deadlines are passed.  And then two years or four years later, a new administration (both state and federal) is in and there is a whole new set of rules to incorporate.  Long term planning just doesn't exist as it does in private industry.  That's the biggest issue in my eyes.


----------------------------------





         

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.