Former federal CIO asks: Why so much custom code in government?

I've seen so much of this as a government contracting programmer for the last 10 years. There was only one time I was able to convince a group in a department to go with an existing tool. It was SSIS, and it made sense over creating some giant unmaintainable XML data interchange format between state and federal agencies.

The most common reasons are:

1) they are unaware of existing products or how to use them effectively. I remember one client who wanted me to implement a complicated feature to remember their position, sorting, and filtering options in a data table. The need was eliminated when I showed them how to middle click and open the record in a new window.

2) they won't, or can't adapt/slightly modify their internal procedures to fit an existing product.

3) they don't understand what they actually do. So they can't evaluate a COTS solution. (part of your job as a consultant is to figure out how things work and design a solution around it)

4) they have too much money. Rare but I've seen it, gotta drain the budget so nothing is left over.

5) they are doing something genuinely different.

6) policies dictate the technologies they are allowed to use

7) legacy databases and reports must persist into a more modern updated interface

>In short, it has to do with the cost of maintaining and supporting code that is unique, often in a language for which it becomes difficult to find programmers and support skills, and the accelerating pace of business change (which often causes major re-writes of custom code).

How is this possible? What ever happened to standardization?

Why is it that the taxpayer always gets f*Ed.?

In government? It's my impression that there is an awful lot of custom code everywhere. Is there anyone who is running SAP/PeopleSoft/Dynamics without a lot of tweaking?

As a federal IT contractor my take on why this is the case; careerism run amok at the expense of elegant solutions.