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

121–130 of 148 posts

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

#121

Post by rosser »

8note wrote: post #111
stupidcar wrote: post #92

Earlier quoted context omitted.

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

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…

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

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

#122

Post by jnbiche »

r00fus wrote: post #74
the_watcher wrote: post #66

Earlier quoted context omitted.

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

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?

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

#123

Post by jessriedel »

dkrich wrote: post #116
jessriedel wrote: post #94

Earlier quoted context omitted.

So it's an accident that this involved fresh hackers from Silicon Valley?

Not an accident- selectivity bias. Ask those hackers to build an app for the USPS, FDA, the DOE or any other agency that imposes strict regulations and has to implement business logic to account for tens of thousands of rules (not an exaggeration) and see how agile and innovative they are. There's a reason that most of these contracts are worth between 7 and 8 figures. That's the kind of manpower required to engineer…

The point is that you went from v1 to v2, and the major thing that changed was the age and attitude of the team. If that sort of dramatic improvement was only conditional on other aspects of the situation, fine, but that doesn't invalidate the article.

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

#124

Post by stupidcar »

dave_sullivan wrote: post #99
stupidcar wrote: post #92

Earlier quoted context omitted.

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

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?

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?

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

#125

Post by arh68 »

I'm excited, skeptical, and interested all at once.

When the hackers leave, who's going to end up doing maintenance on these projects? It's not unusual for a gov't developer to work on a project just long enough to be productive, only to have them leave for greener pastures (often a promotion or relocation). In this case, most will want to stop suffering at lower salary and go back to SV. So it seems like it's going to be USDS holding the bag; unless there's a solid plan to transition the workload back to the VA (either organic or contractor), then USDS will have to maintain every project they start (forever).

On the other hand, I bet there are more than a couple good developers within the VA that would love to take over the projects, if only there were a permanent position they could do it from. Why can't Ash Carter set up more permanent positions?

Worst case scenario, a new President comes in and sunsets USDS, requiring VA to maintain the workload. VA balks, they hand it to Deloitte/BAH/etc, and we're back to square one.

Best case scenario, USDS build quality solutions that last decades and can become the next legacy system that VA builds on. And maybe USDS (if it's still around) can re-revamp the system, etc etc.

Also, I really don't understand the lobbyist's angle on open source: isn't all code written by a federal employee already in the public domain? (with obvious exceptions re: security etc)

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

#126

Post by dave_sullivan »

stupidcar wrote: post #124
dave_sullivan wrote: post #99

Earlier quoted context omitted.

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?

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…

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

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

#127

Post by niels_olson »

liyanchang wrote: post #13
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…

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…

Disclosure: I'm active duty Navy and these are my own opinions.

In 22 years, I have never been so hopeful for meaningful improvement in my work life as I am now. Having met a few folks I am all too familiar with DTS and the JFTR (the 1400 pages in the article(1)). I think that's a great choice to start with: like Google going after the mundane problems of every person's life. This will make a difference. I am on travel now and was on the phone and DTS (simultaneously) for an hour today. And for anyone who tries to apologize for the 1400 pages, please don't. I have cut instructions from 238 pages to less than 30. I would argue the major problem is not that people are trying to solve every edge case. The major problem is that people are only in a job for a short period of time, come in, and while they may try to solve the edge cases they encounter, they often do that by trying to simplify things by inserting a new abstraction and taking ownership of that abstraction. So the layers of abstraction accrete like sediment. And as long as there's no direct logic conflicts, they can promote away from the problem.

I will gladly buy any USDS, 18F, or DDS hacker in San Diego a beer. Keep up the good work.

(1) It's actually 1602 pages: https://www.defensetravel.dod.mil/Docs/perdiem/JTR.pdf

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

#128

Post by niels_olson »

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…

They're referring to the JFTR, now JTR. And it's actually 1602 pages

https://www.defensetravel.dod.mil/Docs/perdiem/JTR.pdf

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

#130

Post by hiram112 »

nitrogen wrote: post #88
temujin wrote: post #85

Earlier quoted context omitted.

Fraud prevention actually is a security issue. Not an Internet security issue, so mistakes aren't punished that quickly, but the analogy is still sound.

Someone buying a new watch with their expense account doesn't suddenly give them access to the whole treasury -- that's the difference between physical and digital realms I am trying to emphasize.

Most security breaches don't allow the malicious user to root the entire server farm either.

I just spent a week fixing permission validation done in JS on the browser. Users could have potentially allowed themselves to see parts of documents outside their role. This didn't give them access to our payroll system, credit card processor, or the backend infrastructure.

Post reply on HN