Finding and fixing date code is one thing -- you know exactly what to look for, and exactly how to fix it.
Finding faulty logic in a program that doesn't work, is another thing entirely.
You can find and fix a lot of “errors” quickly but following the cascading effect of that error throughout the system can be a long term nightmare. Fix one problem in a complex system can break a hundred other processes that are interconnected.
In the old COBOL days we spent months tracking and fixing a main program and 40 or 50 other programs and their files that used output from the main process. The problem was one missing period at the end of a line of code but it required temp fixes to 3-dozen other applications that used the data output from that one program as well as rebuilding the financials files that came from all of those programs.
>>> Finding faulty logic in a program that doesn’t work, is another thing entirely.
As a programmer on IBM mainframes for 12+ years, one of the terms frequently used to describe aged or cumbersome software was: “Spagetti Code”.
Spagetti Code happens as a result of last minute or rushed requirements forced into a system to make it work by the deadline. It also happens as a result of modifying an existing program to do new things instead of streamlining the logic and re-writing a new program. If you look at the Obamacare flowchart, you might get a simplified visualization of what spagetti code can end up looking like.
Besides the obvious problems of decreased maintainability of the code, and increased risk of logic errors, the greatest risk associated with “spagetti code” is that only a select few programmers who are most familiar with the code are able to maintain it... let alone understand it.
It is also the most tried and true way a system programmer can actually manufacture his/her own job security into the software with the valid claim that time constraints prohibited a “cleaner” end product.
Everything I’ve been hearing about what has been done, what has NOT been done, and what they are doing now tells me that at some point in the very near future they will be forced to revert to a manual process while maintaining the requirement that everyone enroll in the system (set up an account) I just read an article yesterday reporting that the Obamacare website included FREE software that was available and was modified to remove copyright credentials... and that the software company that was infringed upon is filing suit.
I’t looks to me like the people who were responsible for designing Healthcare.gov on paper, and passed those requirements on to developers are the same people responsible for manufacturing Obama’s on-line birth certificate...
It reminds me of a popular cartoon where a program manager says to a developer.. “Go ahead and start writing the program... we will provide the parameters and requirements next month.
Now it is next month, and the developers are being asked to fix an un-fixable product in a timeframe that makes the task literally impossible to do.
OH... and the real kicker is this: Starting from scratch will not work either because of the GIGO priciple (Garbage In = Garbage Out) Programs at their core are nothing more than the automation of a manual process that is already proven. Even the designers of the system do not know what they are doing, and will therefore NEVER be able to properly communicate their requirements to developers.