Hacker News new | ask | show | jobs
by cryowaffle 3903 days ago
Glad to see the healthcare.gov debacle leading to a positive shift in mentality at .gov.
1 comments

As someone who worked in the Federal sphere, nothing's changed at all.

The same procurement rules and regulations remain in place with all the issues they cause. 18F is a nice experiment, and they do have some wins, but they are just a drop in the bucket.

The whole procurement and management process is so broken that it's a wonder any project gets completed. The same few bad actors keep winning contracts over and over again, fail, but then don't have any repercussions. In fact, their failures actually net them more money more often than not as contracts get extended now that the contractor has the government by the balls.

IMO the best thing the government could do is a massive in-housing of functions. So much infrastructure within the Federal sphere has contractors essentially acting as PMs, the rank and file builders, the maintenance staff, etc., all with many layers of prime contractors and subs stuffed with middlemen.

This doesn't go just for IT. Lots of simple functions are outsourced to little benefit. Some of it I think might be because it's hard to fire Federal workers and contractors aren't unionized, but it would be better to fix those issues than hire the same person for twice the salary (when accounting for middlemen, margins, etc.)

I'm inclined to agree, but I have two questions regarding that:

1. Aren't government positions notoriously underpaid compared to their private-sector counterparts? 2. Doesn't that mean that "government software" would end up being written by below-average developers and be significantly worse than private-sector software?

Not that #2 isn't possible/likely/a fact under the current system depending on who you speak to.

> 1. Aren't government positions notoriously underpaid compared to their private-sector counterparts?

Yes.

> 2. Doesn't that mean that "government software" would end up being written by below-average developers and be significantly worse than private-sector software?

Assuming that that is the case, the fact that government positions are notoriously underpaid compared to private-sector counterparts would also imply a significant skill deficit in those overseeing and managing government contracts for outsourced work compared to the people employed by the private contractors to exploit the contracting system for maximum profit.

So, if we assume that public sector pay deficits mean, on average, public sector skill deficits, then so long as you don't address the pay deficits, you're stuck with either :

(1) Government software being substandard quality because its made by people with substandard skill working in government, or

(2) Government software being substandard quality because of substandard controls and quality assessment being exercised in the process of contracting out the work to private firms seeking to profit from government contracting process.

> 1. Aren't government positions notoriously underpaid compared to their private-sector counterparts?

Direct Federal hires could be underpaid compared to the private sector, yes. The government uses the General Schedule (GS) scale, which tops out at ~$160K after adjusting for cost of living (there's a base salary and a CoL adjustment). There are rules over who can go in what grade and what step which would likely preclude most SE folks from being compensated appropriately. Those with PhDs and masters degrees would find it easier to get into the appropriate pay band.

Contractors can make good money, and, accounting for not having the middlemen, the Feds should be capable of paying higher salaries for technical fields and still save money. If we're already magically reforming the government by bringing stuff in house (taking an act of Congress in many places; lots of agencies have caps on the number of employees, forcing contractor usage), then we should be able to also reform the pay scale.

>2. Doesn't that mean that "government software" would end up being written by below-average developers and be significantly worse than private-sector software?

Sadly, that's exactly what's in place now. The developers in general are already worse than in the private sector. It's not because of money, it's because of incentives. The Feds aren't good at killing bad projects or disciplining companies they hire.

What you'll see on your typical Booz Allen, Leidos, SAIC, Lockheed, etc. team is a lot of highly educated and experienced people--the government highly incentivizes both education and experience in bidding processes--that are useless. The process beats them down. It's not that they're dumb; they're usually not.

It's difficult to get through the government processes, especially when getting into cleared work. The hiring processes tend to highly favor previous government work, so you end up with the same pool of people. You can't easily hire new people, so you stick with what you've got.

Actually, in my experience the private-sector developers doing government contracts are well paid but are sub par skill wise. The software you work with, the slow procedures and the negativity surrounding failing projects ensure only the mediocre stay, which in turn results in longer and more failing projects. The good developers leave for startups etc.
My (admittedly limited) understanding of why contractors are used instead of government employees is because it's notoriously hard for the government to fire people who aren't good. The premium cost of contractors is worth it when you're able to fire them if they don't meet expectations.
There are many reasons they use contractors. Here are some of the reasons:

1) The agency in question has a hard cap on the number of employees, but has more work than it can accomplish with just this allowed staff. Contractors are the only option.

2) The government is building something and doesn't need (or thinks it doesn't need) to keep the experts around afterwords. For instance, you're building a bridge and won't need all of the construction workers when it's finished.

3) To get around the broken hiring process

4) To get around the broken union rules

5) To theoretically save money vs. doing it in house