This sentence is the simplest explanation for government (and bureaucratic) incompetence.
Think about writing software. Is the optimal solution to every single bug to write more code to deal with that specific situation? Of course not. In many cases, sorting out the underlying cause and fixing that (which may involve new code, rewriting old code, or even deleting outdated code) is the correct approach (assuming that the optimal solution is the desired outcome, there are of course cases where speed of getting something out that works trumps this, but government regulations only take effect once annually in most cases anyway, so they don't have a speed excuse).
Simply writing a new rule to deal with every scenario is an approach that inevitably leads here.
1. Believing that your experience in one particular field makes you qualified to make pronouncements regarding others about which you know nothing.
2. Believing that problems in other fields are inherently simple to understand and solve, and that the reason they aren't must therefore be due to the malice or incompetence of people working in those fields.
3. Believing that software and software development processes are a universal model that can be applied to any other problem via trite and reductive analogy.
The fact there's so much opposition to USDS and 18F that's greater than any other group ever is the best indicator that the fat, bloated Beltway bandits are worried about their easy road to retirement. This isn't to say everyone's lazy - far from it. But government contracting has been largely insulated from the realities of most commercial enterprises through the politicized veil of "protecting veterans" and "defending the country" and for every legitimate, honest worker there's at least two that just want a cushy 9-5 for 35 years.
both code and travel regulations are lists of rules written in a terse language, and both are subject to bloat all of the time, abd parts become deprecated as times and priorities change.
these are very comparable things, e cept that code can change quickly at a low cost, while regulations are costly to change.
Because of the cheapness, software folks have put a lot of effort and study into optimizing how you make rule changes, which makes it very applicable to some other problem spaces
And you don't think that's a salient difference? Particularly in light of the adversarial nature of politics, which was one of your comment's parent's points, and which is a major contributing factor to such changes being so costly?
And your reduction is not even correct. Assuming that problems in other fields are inherently easy to solve has nothing to do with the applicability of software engineering techniques. Assuming those working in other fields are incompetent or malicious has nothing to do with the applicability of software engineering techniques. You say my post was lacking in information density, yet you apparently weren't even able to grasp the arguments I did make. So maybe I needed more explanation, not less?
And are you implying that unless I come up with a solution for efficient government, it somehow renders my — entirely unrelated — argument invalid? That's nothing more than a lame attempt at argumental misdirection. But hey, I'll bite: My solution for operation efficiency in government is for everyone to think and act in the complete opposite manner to you. Is that reductive enough for you?
Consider the software that NASA writes and how it's written. Rigorously specified, reviewed, and tested by some of the best engineers in the world to the point that almost bug-free code is produced at the expense of a much slower rate of development. Which is the best you can do with billions of dollars and human lives on the line for certain projects.
Now look at most government software infrastructure: frequently mercurial and ambiguous software specifications interacting and/or based on flawed laws and regulations filled with logical contradictions written by Congressmen and lobbyists with perverse incentives. And you have to justify every cent or risk the accusation of wasting taxpayer dollars.
Actually NASA culture is to strictly avoid super stars. See:
http://www.fastcompany.com/28121/they-write-right-stuff
In the shuttle group's culture, there are no superstar programmers. The whole approach to developing software is intentionally designed not to rely on any particular person.
And the culture is equally intolerant of creativity, the individual coding flourishes and styles that are the signature of the all-night software world. "People ask, doesn't this process stifle creativity? You have to do exactly what the manual says, and you've got someone looking over your shoulder," says Keller. "The answer is, yes, the process does stifle creativity."
The few NASA engineers I've known have been superb as NASA employees. They weren't grand innovators solving problems on their own, but they were knowledgeable and intelligent. They had deep understanding of the tools they worked with, were rigorously careful and formal, and understood the problems and tradeoffs of their work far beyond any spec they were handed.
To me, that counts as being one of the best engineers in the world. These are people who know what they need to do, why they need to do it, and how they can best accomplish it. In the case of NASA, that generally means doing something radically different than you would at a tech startup, but these people are still brining enormous ability and great care to their work.
With special interests (some of whom may be insiders working to undermine the exact fix that's needed), and you start to get the picture.
To add a bit of spice, address some things like time pressure related to elected administration-specific goals and/or election timeframes.
Go figure.
