3 ms·

Speaking as someone who worked in the past for a government contractor (DoD, so these issues may not be entirely the same with the feds, but I bet they're very

Speaking as someone who worked in the past for a government contractor (DoD, so these issues may not be entirely the same with the feds, but I bet they're very similar), the issue isn't solely that bureaucrats don't get tech, it's also that the bureaucratic red tape that evolved to try and keep costs down has instead led to them rising, -especially- with software. From what I saw, government contracting requires all requirements up front. It then floats a bid, and the cheapest bidder wins. Whether or not the contract has been met is determined by that list of requirements; even if you fail to deliver on a non-functional requirement that is obvious ("the system should be able to scale out and handle X simultaneous users"), you aren't penalized if it wasn't one of the requirements. In fact, delivering on obvious things that aren't part of the contract -hurts the contractor-; it requires development time and effort (and thus eats into profits), and the government is legally prevented from taking such things into account on future contracts (that is, they can't say "Well, company A is the cheapest, but the last contract they took was a broken piece of shit; company B is a little pricier, but they delivered quality, we'll go with company B". No, you go with the cheapest, period, because if they fail to deliver what you specify you can sue, and if they fail to deliver what you -wanted-, but failed to specify, too bad). It's possible to renegotiate the contract mid-stream, but it's expensive and time consuming. So the contractor has every incentive to make sure that there is no time spent on quality, security, stability, scalability, etc, unless that's -explicitly- what was asked for. This article points out that having developers involved from the get go on the Healthare.gov rework led to it being successful, and that's very much true; you need technical people who care about more than just making bank to point out non-functional requirements that are missing. And, in general, trying to list all requirements up front is a fool's game, but such is the government's bidding process.

vonmoltke 10y ago
I was a little too quick on the upvote for your comment. Your first paragraph is spot-on, but your second is not. > the government is legally prevented from taking such things into account on future contracts (that is, they can't say "Well, company A is the cheapest, but the last contract they took was a broken piece of shit; company B is a little pricier, but they delivered quality, we'll go with company B". No, you go with the cheapest, period This is absolutely wrong. There is no requirement that the federal government must go with the cheapest bidder or that they cannot take performance into account. The government can and does regularly reject bids because they are unrealistically low; in fact, I was on one DOD program where both bidders were told to go home and come back with something realistic. Past performance definitely factors in to what the government considers reasonable. It's one of the reasons the government requires labor tracking even in situations where the labor expended doesn't affect the final cost, such as fixed-price contracts and uncompensated overtime.
- lostcolony 10y ago
  That's some comfort then. I never saw any indication of it; across multiple projects I never saw any drive to refactor, or any of the signs I associate with developers taking pride in one's work (documentation above what is asked for, root cause analysis even when a surface issue has been taken care of, or really, any addressing of non-functional requirements that were obvious, but which had not been demanded in the contract). Perhaps because they were mostly long running projects that had already been bidden on, and just having the domain knowledge meant that they'd continue to have the advantage on any future bids to extend it. Also, while I've seen bid wins/losses talked about from the perspective of the quality of the solution, I've not seen them talked about having been won/loss due to past performance. I hope you're right that that's a consideration, but the lack of controls around quality, and the obvious apathy I saw, lends me to think that if that's a consideration, it's not one the government knows how to actually judge.
coredog64 10y ago
To add one more thing, the red tape itself adds non-negligible costs. I once worked for a sovereign native nation, and the community manager was explaining that the amount of money that he got from the Feds for paving a road (IIRC maxed at $50K) was mostly eaten up in labor expended to cover their reporting requirements.
someguydave 10y ago
>From what I saw, government contracting requires all requirements up front. Strictly speaking the government has loads of flexibility at defining exactly what form contracts should take. It's just that in reality, most people who decide on the form of government contracts rarely have the skills required to imagine doing things better. Furthermore they have very little incentive to do so. So the least risky and the simplest option is to "do what didn't work last time". After all, everyone involved (on the government side) will continue receiving paychecks no matter what, so why bother? Also, if you think about it - if you are a median government worker who lacks the skills required to actually perform the task for which you are writing/monitoring the contract - what is the probability that you will do a good job getting results on the taxpayer money you are spending? In the big picture, the taxpayers must employ the most skilled and talented people available to imagine/design/oversee technical solutions acquired by the government if they want any to see value delivered for outgoing tax dollars. This constraint is completely incompatible with the existing civil service personnel policies.

vonmoltke 10y ago

I was a little too quick on the upvote for your comment. Your first paragraph is spot-on, but your second is not. > the government is legally prevented from taking such things into account on future contracts (that is, they can't say "Well, company A is the cheapest, but the last contract they took was a broken piece of shit; company B is a little pricier, but they delivered quality, we'll go with company B". No, you go with the cheapest, period This is absolutely wrong. There is no requirement that the federal government must go with the cheapest bidder or that they cannot take performance into account. The government can and does regularly reject bids because they are unrealistically low; in fact, I was on one DOD program where both bidders were told to go home and come back with something realistic. Past performance definitely factors in to what the government considers reasonable. It's one of the reasons the government requires labor tracking even in situations where the labor expended doesn't affect the final cost, such as fixed-price contracts and uncompensated overtime.

lostcolony 10y ago
That's some comfort then. I never saw any indication of it; across multiple projects I never saw any drive to refactor, or any of the signs I associate with developers taking pride in one's work (documentation above what is asked for, root cause analysis even when a surface issue has been taken care of, or really, any addressing of non-functional requirements that were obvious, but which had not been demanded in the contract). Perhaps because they were mostly long running projects that had already been bidden on, and just having the domain knowledge meant that they'd continue to have the advantage on any future bids to extend it. Also, while I've seen bid wins/losses talked about from the perspective of the quality of the solution, I've not seen them talked about having been won/loss due to past performance. I hope you're right that that's a consideration, but the lack of controls around quality, and the obvious apathy I saw, lends me to think that if that's a consideration, it's not one the government knows how to actually judge.

coredog64 10y ago

To add one more thing, the red tape itself adds non-negligible costs. I once worked for a sovereign native nation, and the community manager was explaining that the amount of money that he got from the Feds for paving a road (IIRC maxed at $50K) was mostly eaten up in labor expended to cover their reporting requirements.

someguydave 10y ago

>From what I saw, government contracting requires all requirements up front. Strictly speaking the government has loads of flexibility at defining exactly what form contracts should take. It's just that in reality, most people who decide on the form of government contracts rarely have the skills required to imagine doing things better. Furthermore they have very little incentive to do so. So the least risky and the simplest option is to "do what didn't work last time". After all, everyone involved (on the government side) will continue receiving paychecks no matter what, so why bother? Also, if you think about it - if you are a median government worker who lacks the skills required to actually perform the task for which you are writing/monitoring the contract - what is the probability that you will do a good job getting results on the taxpayer money you are spending? In the big picture, the taxpayers must employ the most skilled and talented people available to imagine/design/oversee technical solutions acquired by the government if they want any to see value delivered for outgoing tax dollars. This constraint is completely incompatible with the existing civil service personnel policies.