[gunsch]

There are government contractors who are doing this kind of work! There's a group of younger companies that grew up around the Healthcare.gov rescue and work in conjunction with USDS, trying to build cultures of better software development practices in government. Check out the companies in the Digital Services Coalition (https://digitalservicescoalition.org/) and you'll see a lot of companies doing the kind of work you talk about.

I work for Ad Hoc (one of these companies) on software projects at the VA, and I'm happy to chat with anyone who's interested to hear more about this kind of work. I left a cushy Google job to work on important and needed systems, and it does feel so much better!

[brundolf]

But why does it have to go through a contractor system at all? Why can't they keep developers on staff, who among other things can retain institutional knowledge?

[gunsch]

I replied to your other comment at https://news.ycombinator.com/item?id=25975825 about that exact question!

One weird thing we've discovered working on VA.gov for the last five years is that we on the contractor side actually have retained a lot more institutional knowledge than the VA has. It's a problem! We think that knowledge should be on the government side, but the structure isn't there yet: USDS and 18F have rotational term limits that keep people moving through, and at the VA (not sure about other agencies) they're just in the last couple years building out an organization to do that long-term product ownership and institutional knowledge retention, even if implementation teams come through. It's moving in the right direction but it's slow, large-organization change, with a lot of extra slowness that's unique to government.

[flurben]

This would mean having elected officials, top-level managers, who knew what software development was, and prioritized those capabilities over extended periods of time.

The top 2-5 layers of management tend to be the types who want solutions, and they don't care how it works, and they don't really want to be bothered with the details.

To the extent they expend thought at all on systems, they tend to be focused primarily on questions like, "why is all this stuff so confusing?" "who do I blame when this thing goes wrong?"

Where I work, they go through cycles; a higher-up will say "Hey let's build a staff of in-house developers." And they'll do that for 2 or 3 years, until someone reads an article in CIO magazine about how outsourcing is superior. Then they'll start unfairly purging and firing developers, writing code is now "bad", configuration is "Good." This goes on for several years, until the cycle starts over. So as a developer, after you survive your first purge, you begin to see that invisibility is the only way to survive.