Inside the Obama Tech Surge as It Hacks the Pentagon and VA

It's heartening to see some new approaches government IT actually getting high level support to make a positive impact. Funnily enough I see someone I used to work with in one of the pictures.

Hopefully this will lead to more substantive change to how government IT is done. It's great to have teams that can drop into problem areas with a clear mandate to get things moving, but the whole system needs some serious reforms so that these IT quagmires don't get created in the first place.

This article heaps a lot of blame on contractors but fact of the matter is, contractors are often hamstrung by what the customer wants them to do and what the customer allows them to do. And some of that comes back to what was specified in the original contract.

Ultimately there are multiple components to the abysmal state of government IT projects:

* The government has moved to a model where very few full time employees are technical people. The idea is that almost all IT will be outsourced to the private sector

* Because fewer and fewer FTE's are technical, procurement and project management decision-making is compromised.

* There is little accountability for government employees, and by extension, contractors. Botched projects where millions of dollars are waste rarely have major career consequences for FTE's, and the bigger contracting companies don't have their ability to get new contracts affected at all.

* Building software for government often involves arduous interpretation of regulations, trying to build to undocumented and byzantine business processes, or waiting an inordinate amount of time for the bureaucracy to make important decisions (then change their mind!).

I feel like empowering the technical people is a very important first step, and getting them executive backing may create the momentum needed to change some of the common pitfalls. But I think there are some big changes that have to happen to the whole ecosystem to really get things to where they need to be.

It's all well and good to give small teams exceptional power to get around the bureaucracy but that approach doesn't fix the underlying problems.

The contractors are hamstrung by their own business model. I'm sure a lot of the people on the ground are trying to do a good job, but when you're got a set-in-stone spec negotiated by people 4 levels of reporting away from the actual work in the trenches.. yeah that's probably not going to be a spec to do the right thing.

Whether they're contracted or government employees, we need to devolve authority from big top-down specs and towards programmers working alongside the actual users.

The problem is that the contractor doesn't write the RFP or the final contract, the customer does. So if you want that money you sign on the dotted line and hope for the best.

Within the contract there is often flexibility as to how the job gets done. But bottom line is that if you have a stubborn customer who insists on doing things the hard/stupid way, there's not a lot you can do. Maybe you go above their head and try to force a change but that is fraught with risk. The prudent thing to do from a financial standpoint is just put your head down and complete the contract, even if the work is compromised because of the customer you're dealing with. And indeed, that's what happens a lot of the time.

Fortunately more and more parts of government are buying into the agile mindset but there's still a lot of outdated thinking out there.

I think that's part of it, but there's also the facet that a lot of people just...don't care. Families, hobbies, etc are all valid reasons to live for outside of your employment. If the majority do just enough to get by and not get fired (which, as pointed out in other comments, is a pretty low bar in the government, as it is in many large large companies), then the system eventually converges into a sort of homeostasis of mediocrity, which is viciously self-preserving [1].

---

[1] these together are pieces of Yudkowsy's revision of Hanlon's Razor: "Never attribute to malice what you can attribute to an enormous complicated System full of conflicting incentives getting stuck in a weird equilibrium. When that weird equilibrium is crushing people in its gears... We see a broken watch and infer a Watchbreaker."

I'm curious if anyone here from USDS or 18F has deployed Postgres in a FIPS 140-2 environment, and if so what challenges they had. The VA seems to be saying that Postgres should not be used:

http://www.va.gov/TRM/ToolPage.asp?tid=5692&tab=2

contrast that with Oracle:

http://www.va.gov/TRM/ToolPage.asp?tid=9&tab=2

(Don't miss the difference in tone on the "Analysis" tabs.)

I'm sure some of that is due to lobbyists, but nonetheless it seems to me that there are legitimate challenges in making Postgres meet FIPS 140-2 requirements. I've been able to recompile Postgres to use the FIPS OpenSSL wrapper, but storing passwords with MD5 is a harder issue to fix, and of course there is no definitive list. Does anyone have some experience with this?