The part of the post that attempted to decode some of this
testimony was far too mild and forgiving in three respects:
1) When the testimony discussed the lask of an "inventory"
and the lack of code documentation, the analysis assumed that
the IRS could at least find the source code. Frankly, I suspect
that they are running some programs for which the source code
in unavailable, or almost as bad, for which the precise method
for building the object from the source has been lost.
2)The analysis does not question the date given in the testimony
which the softwre problems occur: July 1999. I strongly suspect
that there are "future date" fields which will need the correct
value of 2000 or later, but which must be entered into the systems
starting next year. Further, I strongly suspect that some
of the IRS systems are coded such that the number "99" is a
special-case marker meaning "don't know" or "don't care" or
"infinity". This was a standard COBOL coding practice.
3) The analysis notes that the IRS's "plan" to award a
contract to one or more large firms to fix the problem
is a fantasy. The "plan" calls for contract award in
October 1998 for delivery of a new system in July 1999.
The analysis notes that this allows 8 months to complete
62 million man-days of programmer effort. In truth, the
real problem is much worse, since There would be a
considerable lag from the time of contract award until the
timethe project could be organized. (The 62 million man-day
estimate is my own, based on the 62 million lines of source code
given in the article.)