5 ms·

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 proble

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 rule. The fact that it takes some projects years to deploy is that we would like to plan and make sure that every resource is well-spent, that it's in a number of languages and accessible to the blind. It makes it hard for everyone - I've met lots of smart talented civil servants and government contractors who want to do things differently but have their hands tied behind their back. [0] 2 years feels like forever to me but flash in the pan to many of the dedicated civil servants I've met.

cs702 10y ago
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 likely consist primarily of thousands upon thousands of assertions and if-then statements. I wonder if it would be possible to reduce them to, say, a few dozen pages -- by refactoring all that 'regulatory code' to use different, higher-level abstractions.
- tonysdg 10y ago
  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 people problems in the same light; the former can be solved much easier than the latter. The trick is to figure out where you can solve the former to avoid the latter!
  - sliverstorm 10y ago
    Not in government, but I understand the biggest problem with travel to be the expense account, which has a history of being abused to disgusting proportions.
  - niels_olson 10y ago
    They're referring to the JFTR, now JTR. And it's actually 1602 pages https://www.defensetravel.dod.mil/Docs/perdiem/JTR.pdf https://www.defensetravel.dod.mil/Docs/perdiem/JTR.pdf
  - Bartweiss 10y ago
    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.
DannyBee 10y ago
"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 it. IE it's likely 50 pages of those regulations gave them a 99.9%+ rate of avoiding fraud. They then added 1350 pages to get to probably 99.99% This is unlikely to be worth it. (and yes, before someone points it out, i'm likely being generous with the numbers)
- dastbe 10y ago
  Unfortunately there are a lot of people who believe government shouldn't do anything unless it is fraud-proof. The narratives around welfare and food stamp abuse make headlines for exactly this reason :(.
  - el_benhameen 10y ago
    I think their intentions are a little more nefarious. It's not that they want e.g. a fraud-free welfare system; they fundamentally disagree with the idea of welfare and so use fraud, whether it's a legitimate issue or not, as a basis for trying to stymie or dismantle the institution.
- sliverstorm 10y ago
  People are pretty sensitive about government financial workers committing fraud, similar to how they are rather sensitive to government police committing murder.
  - DannyBee 10y ago
    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 "and also don't shoot them while they are handcuffed" isn't necessary. Crappy post-justification does mean the regulation was written wrong, and changing the regulation to account for the post-justification will not actually improve the process most of the time.
the_watcher 10y ago
> 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.
- r00fus 10y ago
  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 10y ago
    > That's fine in writing software - now try that in an adversarial environment. Oh, software is not an adversarial environment?
    - evgen 10y ago
      Software development is little league compared to the major league bloodsport of bureaucratic politics played inside the beltway.
- rosser 10y ago
  Funnily enough, it turns out that collections of humans interacting isn't like software. Go figure.
- stupidcar 10y ago
fapjacks 10y ago
I want to work there so bad. USDS or 18F. But I can't get anyone to call me back, even with twenty years working in (and running) startups. Dunno what that's about.
- aschonfeld 10y ago
  Hi Fapjacks. I'm on the talent team at 18F. Feel free to email me directly at amanda.schonfeld@gsa.gov. We don't have a direct phone number for folks to call, but I will definitely email you back. :)
bsaul 10y ago
Very informative comment, but then, did that change once the usds were in charge ? Because my intuition is that taking over an openly failed project makes it easy for the new team to tell everyone to try and keep things simple. Then wouldn't the succes not be a matter of technical abilities or process, but rather goodwill by the client side to remain reasonable ?
niels_olson 10y ago
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 https://www.defensetravel.dod.mil/Docs/perdiem/JTR.pdf

cs702 10y ago

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 likely consist primarily of thousands upon thousands of assertions and if-then statements. I wonder if it would be possible to reduce them to, say, a few dozen pages -- by refactoring all that 'regulatory code' to use different, higher-level abstractions.

tonysdg 10y ago
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 people problems in the same light; the former can be solved much easier than the latter. The trick is to figure out where you can solve the former to avoid the latter!
- sliverstorm 10y ago
  Not in government, but I understand the biggest problem with travel to be the expense account, which has a history of being abused to disgusting proportions.
- niels_olson 10y ago
  They're referring to the JFTR, now JTR. And it's actually 1602 pages https://www.defensetravel.dod.mil/Docs/perdiem/JTR.pdf https://www.defensetravel.dod.mil/Docs/perdiem/JTR.pdf
- Bartweiss 10y ago
  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.

DannyBee 10y ago

"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 it. IE it's likely 50 pages of those regulations gave them a 99.9%+ rate of avoiding fraud. They then added 1350 pages to get to probably 99.99% This is unlikely to be worth it. (and yes, before someone points it out, i'm likely being generous with the numbers)

dastbe 10y ago
Unfortunately there are a lot of people who believe government shouldn't do anything unless it is fraud-proof. The narratives around welfare and food stamp abuse make headlines for exactly this reason :(.
- el_benhameen 10y ago
  I think their intentions are a little more nefarious. It's not that they want e.g. a fraud-free welfare system; they fundamentally disagree with the idea of welfare and so use fraud, whether it's a legitimate issue or not, as a basis for trying to stymie or dismantle the institution.
sliverstorm 10y ago
People are pretty sensitive about government financial workers committing fraud, similar to how they are rather sensitive to government police committing murder.
- DannyBee 10y ago
  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 "and also don't shoot them while they are handcuffed" isn't necessary. Crappy post-justification does mean the regulation was written wrong, and changing the regulation to account for the post-justification will not actually improve the process most of the time.

the_watcher 10y ago

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

r00fus 10y ago
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 10y ago
  > That's fine in writing software - now try that in an adversarial environment. Oh, software is not an adversarial environment?
  - evgen 10y ago
    Software development is little league compared to the major league bloodsport of bureaucratic politics played inside the beltway.
rosser 10y ago
Funnily enough, it turns out that collections of humans interacting isn't like software. Go figure.
stupidcar 10y ago

fapjacks 10y ago

I want to work there so bad. USDS or 18F. But I can't get anyone to call me back, even with twenty years working in (and running) startups. Dunno what that's about.

aschonfeld 10y ago
Hi Fapjacks. I'm on the talent team at 18F. Feel free to email me directly at amanda.schonfeld@gsa.gov. We don't have a direct phone number for folks to call, but I will definitely email you back. :)

bsaul 10y ago

Very informative comment, but then, did that change once the usds were in charge ? Because my intuition is that taking over an openly failed project makes it easy for the new team to tell everyone to try and keep things simple. Then wouldn't the succes not be a matter of technical abilities or process, but rather goodwill by the client side to remain reasonable ?

niels_olson 10y ago

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 https://www.defensetravel.dod.mil/Docs/perdiem/JTR.pdf