[the_watcher]

> every single issue that comes up results in a new rule.

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.

[stupidcar]

You demonstrate intellectual fallacies common amongst software developers:

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.

[devonkim]

With these considerations taken we can apply the same problems to people in industrial scale manufacturing that have typically managed many organizations that are now in charge of software projects. Then comes no real effective incentive structure with how most federal contracts are written despite billions spent on lawyers to protect the government and to get the most for the government's dollars supposedly. I've seen far too many projects with clearly the most talented and well-managed contractors getting tossed for actually finishing their deliverables while those that didn't get through 40%+ got renewed because they were just too critical to the political success of the greater project. And they'll continue to cite the project as past performance and renewal as an indicator of competence.

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.

[8note]

while i frequently agree with you, i disagree here.

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

[rosser]

> ...except that code can change quickly at a low cost, while regulations are costly to change.

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?

[dave_sullivan]

Yet the information density of the parent comment is so much higher. You have 3 statements that can be reduced to "Things that work in programming don't necessarily work in other fields." No kidding? Then what's your solution for operational efficiency in government?

[stupidcar]

Some of us believe detail and nuance add power to argument, rather than rejecting them in favour throwing around basic, unsupported claims.

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?

[dave_sullivan]

> And are you implying that unless I come up with a solution for efficient government, it somehow renders my — entirely unrelated — argument invalid?

I'm implying that you're long-winded and it weakens your argument. If I reduced your response, I'd reduce it to, "You hurt my feelings and I'm angry about that." Fair enough, but the rest is so much filler.

[r00fus]

That's fine in writing software - now try that in an adversarial environment.

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.

[jnbiche]

> That's fine in writing software - now try that in an adversarial environment.

Oh, software is not an adversarial environment?

[evgen]

Software development is little league compared to the major league bloodsport of bureaucratic politics played inside the beltway.

[sn9]

Writing software for whom?

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.

[nn3]

>Rigorously specified, reviewed, and tested by some of the best engineers in the world

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."

[Bartweiss]

I think equating "best engineers" with "superstars" means you might be bringing your own associations to the topic. (Not unfairly, that's a standard association in the Valley, but still.)

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.

[sn9]

I never said anything about superstars. That's precisely one of the articles that most informs my understanding of NASA software practices.

[rosser]

Funnily enough, it turns out that collections of humans interacting isn't like software.

Go figure.