If you want to understand IRS dysfunction, let me explain it this way: IRS computer programs have been subjected to major changes every year for over 60 years.
For a few years, I toiled as a computer programmer at the IRS. The agency’s technology is antiquated, non-standard, and poorly designed. After 60 years, it possesses little to no cohesive support documentation.
And every time Congress passes changes in the tax code, the IRS must hard code every single change into this unwieldy mass of antiquated computer programs. It doesn’t help that Congress is constantly tinkering with the tax code, often at the behest of special interests.
This has resulted in a programming infrastructure that looks and operates like a terminally ill patient clinging to life after 60 major operations.
And yes, these are the same computer programs that process your annual tax returns; thousands of programs, each with multiple authors who has made changes according to their personal preference and background, as opposed to a defined and documented set of best-practice standards.
As a result, each code change must first be analyzed and integrated to see what impact it will have on other proposed changes and the existing tax code. Then and only then can programmers determine which of the thousands of programs must be modified, and prepare a design document to initiate the needed changes.
Shockingly, these design documents have never been integrated into a single master design record — a historical roadmap that would enable programmers over time to quickly understand the totality of their assigned programs. If the IRS were to begin this task now, they would have to integrate literally thousands of design documents that have been created over six decades — an utterly impossible task.
In private industry, most private sector programmers excel in math and possess a college degree in Information Technology. And they adhere to a set of strictly defined programming standards.
The IRS prefers to send the same field agents you deal with in IRS offices (who know nothing about computer programming) to multi-week programming classes taught by former field agents who were also cross-trained in computer programming.
This is why the IRS technology situation is so ugly.
In the early 1960s, data was represented on IBM mainframes in a format called BCD code. When the IRS migrated to the IBM/360 line of mainframe computers, the data was represented in a format called EBCDIC. The IRS chose to keep the old BCD format; simply translating it to EBCDIC at points in the program where the text needed to be printed or displayed while keeping the old BCD format in the files. Amazingly, this practice continues today.
Have you ever wondered where the IRS keeps the files containing your tax data? Yes, we may live in 2014, but it’s all on magnetic tape, as if we were living in the 1960s.
And all those thousands of programs that process your tax returns are written in the Basic Assembler programming language (BAL), which can only be used on ancient IBM mainframes. This means all IRS programs must operate on IBM mainframes. To move them to a different platform — for example, modern servers, mid-range computers, or even distributed to PCs — would require the IRS to manually translate the BAL source language to another language, an undertaking too costly even to consider.
The IRS IT department is very, very sick. Any attempt at a major operation would most likely prove catastrophic.
It is just a matter of time before the patient passes away.
John Bodoh is a retired computer programmer who spent three years in the IRS as a contract software programmer. Thinking of submitting an op-ed to the Washington Examiner? Be sure to read our guidelines on submissions for editorials, available at this link.
