The disconnect between software development and government contracting. – Waldo Jaquith

The key philosophical difference between modern software development and government contracting:

This has left a fundamental disconnect between contracting practices (specifying everything is safest) and software development practices (specifying everything is dangerous).

So stop buying software—buy the time and skills of people building software:

The way I’ve sold this to contracting officers is with this point: When buying custom software, you’re not buying a product. You’re buying a service, the service of developers building software, with features as prioritized by a government product owner.

You can hire them, too, but Waldo’s point is that “contracting out” doesn’t have to be so terrible, if we do it right: by contracting people or teams, and structuring contracts such that we can stop working with them and work with someone else if their work is unsatisfactory. The software remains in the government’s hands, the overall project within the government’s control (which makes sense, because they’re ultimately responsible, no matter who’s delivering it), and the people working on it have incentive to actually deliver.

Anecdotally, I’m reminded of the contract for the Phoenix payroll system, which I once saw an ATIP’ed copy of (freedom of information request, sensitive portions redacted). It was the worst of both worlds: the contract stipulated in great detail what the delivered software had to do, while also stipulating in great detail the kinds of roles the contractor had to hire to work on that software (down to people’s education levels and experience—essentially mirroring the government software workforce’s standardized roles). Don’t do the former; do the latter, but better.