Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside the Obama Tech Surge as It Hacks the Pentagon and VA

backchannel.com

Post reply on HN
Print view View original

131–140 of 148 posts

Re: Inside the Obama Tech Surge as It Hacks the Pentagon and VA

#131

Post by [deleted] »

DannyBee wrote: post #77
sliverstorm wrote: post #44

Earlier quoted context omitted.

People are pretty sensitive about government financial workers committing fraud, similar to how they are rather sensitive to government police committing murder.

Sadly, in neither case will you ever have 100% compliance. Pretending it's achievable, and trying to achieve it, is IMHO, silly. Remember the regulations do not prevent fraud, enforcement prevents fraud. There already exist plenty of things saying it's not okay, etc. Saying "and also, don't do that" is probably not actually necessary most of the time, in the same way saying "don't shoot people" is sufficient. Saying…

[deleted]

Re: Inside the Obama Tech Surge as It Hacks the Pentagon and VA

#132

Post by travmatt »

chatmasta wrote: post #38
cs702 wrote: post #7

The federal government hires a team of young, talented, motivated engineers and managers, puts them in charge of failed software projects, gives them the resources and authority they require to turns things around, and -- surprise! -- it turns out they do a GREAT job. In hindsight, this shouldn't be too surprising. What might be surprising is that the same logic should apply to ALL government functions, not just soft…

Some government functions are intentionally poorly run. See the recent FOIA debacle, for instance.

On the flip side, republicans try to sabotage the functioning of many agencies so that they can then complain that the private sector would be a better fit. This has been their MO towards the Post Office for longer than I've been alive, and have been diligently working to undermine social security in the hopes that may be privatized as well. It's the 'starve the beast' strategy on a larger scale.

Re: Inside the Obama Tech Surge as It Hacks the Pentagon and VA

#133

Post by di4na »

vonmoltke wrote: post #68
saosebastiao wrote: post #55

Earlier quoted context omitted.

In terms of security, that is probably exactly correct (I'm a complete security novice FWIW). Way too high of an attack surface area. That being said, as soon as you get into microcontroller territory, you turn it into a niche thing that makes it inaccessible to most. What are the chances of finding talent that can write user-facing code that runs bug free on microcontrollers while simultaneously writing/proving the…

Why does dropping the OS mean you have to run on microcontrollers and write everything from scratch? All it means is your software needs to incorporate the OS functions that it needs for interacting with the hardware. You can still use any hardware platform you want and any third-party libraries available for said platform.

Which is exactly what micro controllers programming is.

I worked and still do some work for embedded programming. If you never did it before : OS make life super super easy. Really.

Re: Inside the Obama Tech Surge as It Hacks the Pentagon and VA

#134

Post by evgen »

jnbiche wrote: post #122
r00fus wrote: post #74

Earlier quoted context omitted.

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.

> That's fine in writing software - now try that in an adversarial environment. Oh, software is not an adversarial environment?

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

Re: Inside the Obama Tech Surge as It Hacks the Pentagon and VA

#135

Post by sn9 »

nn3 wrote: post #110
sn9 wrote: post #102

Earlier quoted context omitted.

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 i…

>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 c…

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

Re: Inside the Obama Tech Surge as It Hacks the Pentagon and VA

#136

Post by Bartweiss »

nn3 wrote: post #110
sn9 wrote: post #102

Earlier quoted context omitted.

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 i…

>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 c…

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.

Re: Inside the Obama Tech Surge as It Hacks the Pentagon and VA

#137

Post by Bartweiss »

tonysdg wrote: post #34
cs702 wrote: post #25

Earlier quoted context omitted.

Thank you for posting here. The same logic applies to all those regulations that seem bonkers. If you think of all those regulations as a type of source code (which dictates what government employees and citizens can and cannot do, when, and under what conditions), it's clear that a lot of regulatory code needs major refactoring. To use your example with travel regulations, those 1400 pages designed to prevent fraud…

My guess is that most of those 1400 pages consist of the corner cases - things that will 95% of the time never pop up, but when they do will wreak havoc unless properly dealt with. Granted, I'm not sure travel fraud can wreak that much havoc, but I'm sure someone somewhere gets annoyed over it. My (admittedly limited) experience in coding/engineering has taught me that it's unwise to look at technical problems and pe…

Frankly, my take is that this is what happens when you try to beat human intent with formal rulings. Explicitly banning every possible form of travel fraud is almost unimaginable - certainly it can't be done without banning a huge amount of legitimate travel also. Rigorous safety around people problems is nigh-impossible, which is why most safe software systems take the approach of "do it our way or go to hell".

At a certain point you can only solve the people problems with oversight and good intentions. You could get one random employee to certify any given travel plan or reciept as "not obviously fraudulent" and recreate the benefit of ~700 pages of regulations, just by showing the thing to someone who doesn't benefit from fraud.

But of course, incremental change produces these kind of awful local minima. If you are punished for fraud, aren't punished for overhead, and can't change the whole system, what else would you do? You ban one known misbehavior, go on with your day, and everything gets a little bit worse.

Re: Inside the Obama Tech Surge as It Hacks the Pentagon and VA

#138

Post by Bartweiss »

DannyBee wrote: post #33
liyanchang wrote: post #13

Earlier quoted context omitted.

Disclosure: I'm an engineer at USDS and these are my own opinions. So in my admittedly short time in the government [0], I've witnessed how all of these problems are due to good intentions. That's what makes this all really tough because everything you think is bonkers actually has a reason. The 1400 page travel regulations is a result of trying to prevent fraud - every single issue that comes up results in a new rul…

"The 1400 page travel regulations is a result of trying to prevent fraud - every single issue that comes up results in a new rule." This seems like a serious inability to understand that no process designed to prevent future things you can't forsee is 100% effective (by definition). At some point, you have to declare "good enough", and live with it until the error rate becomes unacceptable overall again, then modify…

This is exactly the problem. When you have a system that completely ignores inefficiency/overhead but goes berserk over fraud, you get totally absurd incentives. Those 1350 pages probably kept some managers from getting fired, but realistically have been a serious waste of time and money.

At a certain point, you either accept a low level of fraud or just make a rule saying "don't do bad, wasteful stuff." Then you fire anyone who breaks that rule and let things work themselves out. (This has other problems, but they can be addressed.)

Most of bureaucratic stupidity is ultimately moral hazard. Someone pays for one failure case but not another, so they spend absurd amounts minimizing what they're responsible for.

Re: Inside the Obama Tech Surge as It Hacks the Pentagon and VA

#139

Post by Bartweiss »

azernik wrote: post #117
DannyBee wrote: post #78

Earlier quoted context omitted.

This is a generally true statement about any process. The solution to that is to enforce well enough that people don't think that's a good idea. I also did say you do have to refactor over time as compliance rate decreases. Past that, i don't think we actually disagree :) If you have a speed limit sign, and it says "speed limit, 50 mph, enforced by satellite observation", most people will probably ignore it. Those th…

You cannot fix a loophole with better enforcement. By definition, the behaviors involved are allowed .

I'm not convinced about that.

Some organizations do startlingly well with good enforcement and a rule against circumventing the rules. Yes, that's subjective and messy, but it can actually work quite nicely.

Hell, it's basically what financial structuring laws are: a rule saying "no using loopholes if you find them". With that in place, it becomes surprisingly easy to address loopholes by punishing everyone who employs them.

Re: Inside the Obama Tech Surge as It Hacks the Pentagon and VA

#140

Post by Bartweiss »

nitrogen wrote: post #83
learc83 wrote: post #76

Earlier quoted context omitted.

This is analogous to adding code to cover security issues. 99.9% isn't good enough when people are actively looking to exploit the 0.1%.

But unlike security issues a single failure doesn't compromise 100% of the rest of the system. This is also why analogies between software/security/cryptography/privacy and the tangible world are so awkward.

This is a big part of the answer. Congressional hearings and reporting often act like "fraud is fraud", but allowing 1% fraud to save 20% overhead is entirely reasonable.

Improper resource usage is a better metaphor than security failures for this topic.

Post reply on HN