How a team of young people helped rebuild healthcare.gov

Not to take anything away from the "young people" -- who are ages 28+ -- but this article over-sensationalizes their accomplishments.

  "The MPL team had three great technical accomplishments over its 16-
  month-long life. First, it served as a crack team which understood the
  infrastructure of the site and could resolve small issues as they arose. 
  Second, it built an insurance application, called App2, which signed up 
  new users in less than half the time of the original app. Finally, it 
  replaced the website’s crashy login system with a functional (and much 
  less expensive) one of its own design."

I know the author wants a "startup" narrative, but these aren't groundbreaking accomplishments, let alone the fact #1's silly.

  "It did most of this while living together in an unremarkable McMansion in suburban 
  Maryland."

I don't understand why this matters.

  "So the team that started by performing bug fixes on a sprawling, struggling mass 
  of code ended by writing critical, efficient infrastructure for the government. 
  Yet what the MPL team accomplished philosophically may be even more important: 
  It helped teach government bureaucrats how to think about building websites in 2015."

The author tried too hard to overlay a ScrappyStartup™ narrative. This argument is absurd.

edit: stephengillie called it in his "submarine" comment below (see: http://www.paulgraham.com/submarine.html)

Not just youth worship, youth genius worship.

Having been subjected to the government's definition of "agile" before[1], I can tell you that nearly everyone who was at least barely competent technically[2] thought the processes were asinine. The problem is that nobody could convince the government customers and non-technical management of this. The government in particular was bad, as their reps (GS and contractor) often came in with a dictatorial, know-it-all attitude about the problems they were hiring us to solve.

This team managed to do what they did because they were outsiders brought in specifically to fix a high-profile fuck-up. I'm willing to bet that most of what they did was suggested at some point by people who worked on the broken system, but it was shot down. The success of the second effort was primarily political.

[1] The Gantt chart bit brought back memories that made me want to throw things.

[2] Despite stereotypes to the contrary, most developers and engineers working at government contractors are at least barely competent. Contractors with mature engineering orgs (Raytheon, Boeing, Lockheed, etc) are better as they tend to force the fuck-ups out pretty quickly.

Is there any more information about the inner workings of the failed healthcare.gov site? It's quite interesting to read how horribly wrong they got it.

As usual, a fix-it team does 80% of the work in 20% of the time for 5% of the money.

Speaking as an old, I think youth is part of the answer. One of the things I have to really work at as I get older is unlearning the things that used to be true. Given the pace of technological change, younger people have an advantage in that they have less to unlearn.

> Start-up culture and tech trends just don't work at the scale of government, for much the same reasons massive corporations move glacially.

This is good example of an old truth that needs some unlearning. Old corporations move glacially. Some new ones work differently, though.

Government can also work differently. The folks at 18F and the US Digital Service are demonstrating that in ways both large and small. Indeed, when I was looking at a USDS job, a White House advisor told me plainly that agile, iterative approaches were clearly better for government because they were much more effective at risk reduction than producing piles of documents ever could be.