4 ms·

I just got through speaking in DC about Agile, startups, and functional programming, mostly to an audience that is intimately familiar with government work. It'

I just got through speaking in DC about Agile, startups, and functional programming, mostly to an audience that is intimately familiar with government work. It's really bad when you try to be diplomatic about how bad things are fucked up and get open laughter from the crowd. There's no BSing people who live this everyday. Talking with folks afterwards, I heard about systems that I could have rewritten in the late 90s in a few months that are still in the process of being rewritten, 15 years later. After literally hundreds of people have worked on them costing the taxpayer millions of dollars. And these are not unique or oddball edge cases. Stuff like that is standard operating procedure. I can't impress on the HN audience enough how terrible federal IT is overall. (Aside from some really great outliers). There's a vast and increasingly large gap between political rhetoric and the reality on the ground. This has been true for at least the last 20 years. I take issue with some of the details the supporting argument makes here, but that's mostly a quibble. The author is definitely headed in the right direction. I'm a veteran of several federal IT programs, and a real veteran. I have seen some really good federal teams, but never a good federal team of teams. It all falls apart once you get past a few people and start throwing some kind of structure and management in place. I understand that Agile is becoming required for some federal work, but I'll bet you a thousand bucks this kind of "Agile" isn't going to be the kind that the rest of us use. Think big tools, big management, lots of stupid measurements, and no accountability. All with the word "Agile" stamped on the front of it. ...The bottom line is that federal IT programs' success is measured by things that have nothing to do with how successful they are or by the metrics most of the world uses. While the business world (and Web companies in particular) now monitor user experience and productivity as a metric for IT success, the government keeps throwing out numbers that mask the truth: the only people who would use their systems are the ones that are forced to... Yep.

Jtsummers 13y ago
"Agile" when federalized will probably turn out like "Lean". Lean in manufacturing and similar processes, when done right, is a good thing. However, the government version of it is almost a complete perversion of the intent. Instead of bottom up, employee-driven changes, it's top down based strictly on metrics and the changes typically effected so that whoever's currently in charge can say, "I made <process> 10% more efficient by reducing the number of wasted <things>." Employees resist the changed processes/taskings because they fear a loss of employment, and are kept out of the loop when the changes are being devised. Federalized Agile would likely be similar.
- DanielBMarkham 13y ago
  Yep. We saw this same thing with source control. Who doesn't like source control? But the government, in an effort to make sure there was absolutely no risk, mistakes, or accountability associated with software development, started adding more and more mandatory forms that had to be completed each time a developer checked something back in. This created such a mess for developers that it wasn't unusual for one check in to take hours to accomplish. You'd read a book while the system tried to accept your code changes. Agile is all about failing fast and learning quickly. Most contractual work for the government does not include the possibility of failure. At all. In fact, the way the contracts are written is such that the contractor takes on all responsibility for everything, even things there's no way they could control. In response to this idiotic situation, contractors start bidding at crazy low rates on these things, say 40 bucks an hour, then actually make their money on changes. So it's always in the contractors interest to capture and execute changes, while it's the government is trying to get the world delivered to them on a platter for five bucks. People use the term "perverse incentives", but this is like that taken to the next level. It's a multi-layered thing. It's total systemic failure. We'd call it systemic collapse, but the money keeps flowing in anyway, so that term isn't applicable, although it certainly feels like it. This kind of distrust doesn't make for anything but a living hell for everybody, government employees and contractors alike. So, with tons of rules and structures in place, the way things really work is through relationships. People who are easy to get along with and helpful get more government work. Both sides of the fence can't control the process, and nobody rocks the boat and everybody gets a piece of the pie. You end up from the government side with some sort of informal and unspoken version of I don't care if you make a lot of money, just make sure me and my friends look good Also it'd be nice to pick up a little lucrative consulting work once I've put in my 20 and can start double-dipping. Your average developer has absolutely no idea about this. If they've worked in IT in federal work, they probably have horror stories, but the more you see the worse it gets. Oddly enough, in the best cases you end up with people who really like working together, are motivated, but spend most of their time fighting a Sisyphean fight against the idiocy of the system.
  - mtts 13y ago
    > But the government, in an effort to make sure there was absolutely no risk, mistakes, or accountability associated with software development, started adding more and more mandatory forms that had to be completed each time a developer checked something back in. That's because "the government" is operating under different pressures than corporations. A corporation, big or small, screws up, only a handful of stakeholders are affected and raise a stink. If the government screws up, you're looking at headlines in the Washington Post. Plausible deniability is a powerful force.
dragonwriter 13y ago
> I understand that Agile is becoming required for some federal work, but I'll bet you a thousand bucks this kind of "Agile" isn't going to be the kind that the rest of us use. Agile can't be mandated; you can mandate methodologies (e.g., Scrum), but by the very act of mandating a methodology you are not agile. Agile is a culture, and it is a culture of flexibility in methodology with focus on the goal. And its a culture that is very much contrary to the entrenched culture of most large bureaucracies, government or private (and, in government, often in tension with binding mandates where the authority to make changes to the mandate is very distant from the locus at which one would normally expect efforts to adopt development approaches.)
jfb 13y ago
It all falls apart once you get past a few people and start throwing some kind of structure and management in place. That's hardly confined to Federal IT projects, however.

Jtsummers 13y ago

"Agile" when federalized will probably turn out like "Lean". Lean in manufacturing and similar processes, when done right, is a good thing. However, the government version of it is almost a complete perversion of the intent. Instead of bottom up, employee-driven changes, it's top down based strictly on metrics and the changes typically effected so that whoever's currently in charge can say, "I made <process> 10% more efficient by reducing the number of wasted <things>." Employees resist the changed processes/taskings because they fear a loss of employment, and are kept out of the loop when the changes are being devised. Federalized Agile would likely be similar.

DanielBMarkham 13y ago
Yep. We saw this same thing with source control. Who doesn't like source control? But the government, in an effort to make sure there was absolutely no risk, mistakes, or accountability associated with software development, started adding more and more mandatory forms that had to be completed each time a developer checked something back in. This created such a mess for developers that it wasn't unusual for one check in to take hours to accomplish. You'd read a book while the system tried to accept your code changes. Agile is all about failing fast and learning quickly. Most contractual work for the government does not include the possibility of failure. At all. In fact, the way the contracts are written is such that the contractor takes on all responsibility for everything, even things there's no way they could control. In response to this idiotic situation, contractors start bidding at crazy low rates on these things, say 40 bucks an hour, then actually make their money on changes. So it's always in the contractors interest to capture and execute changes, while it's the government is trying to get the world delivered to them on a platter for five bucks. People use the term "perverse incentives", but this is like that taken to the next level. It's a multi-layered thing. It's total systemic failure. We'd call it systemic collapse, but the money keeps flowing in anyway, so that term isn't applicable, although it certainly feels like it. This kind of distrust doesn't make for anything but a living hell for everybody, government employees and contractors alike. So, with tons of rules and structures in place, the way things really work is through relationships. People who are easy to get along with and helpful get more government work. Both sides of the fence can't control the process, and nobody rocks the boat and everybody gets a piece of the pie. You end up from the government side with some sort of informal and unspoken version of I don't care if you make a lot of money, just make sure me and my friends look good Also it'd be nice to pick up a little lucrative consulting work once I've put in my 20 and can start double-dipping. Your average developer has absolutely no idea about this. If they've worked in IT in federal work, they probably have horror stories, but the more you see the worse it gets. Oddly enough, in the best cases you end up with people who really like working together, are motivated, but spend most of their time fighting a Sisyphean fight against the idiocy of the system.
- mtts 13y ago
  > But the government, in an effort to make sure there was absolutely no risk, mistakes, or accountability associated with software development, started adding more and more mandatory forms that had to be completed each time a developer checked something back in. That's because "the government" is operating under different pressures than corporations. A corporation, big or small, screws up, only a handful of stakeholders are affected and raise a stink. If the government screws up, you're looking at headlines in the Washington Post. Plausible deniability is a powerful force.

dragonwriter 13y ago

> I understand that Agile is becoming required for some federal work, but I'll bet you a thousand bucks this kind of "Agile" isn't going to be the kind that the rest of us use. Agile can't be mandated; you can mandate methodologies (e.g., Scrum), but by the very act of mandating a methodology you are not agile. Agile is a culture, and it is a culture of flexibility in methodology with focus on the goal. And its a culture that is very much contrary to the entrenched culture of most large bureaucracies, government or private (and, in government, often in tension with binding mandates where the authority to make changes to the mandate is very distant from the locus at which one would normally expect efforts to adopt development approaches.)

jfb 13y ago

It all falls apart once you get past a few people and start throwing some kind of structure and management in place. That's hardly confined to Federal IT projects, however.