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.
> It helped teach government bureaucrats how to think about building websites in 2015.
I think this is true. Governments and corporate's are starting to see that you don't need to go with GenericAdAgency12 anymore to get shit-hot, well-made websites going. This project was a textbook example of this.
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.
> This team managed to do what they did because they were outsiders brought in specifically to fix a high-profile fuck-up.
This is true. But having recently talked with a number of people at 18F and the USDS, I think the enormous scale of the high-profile fuckup is serving as a great example to persuade people that things should be done differently.
For example, note that the government is trying to change the purchasing processes that drive heavyweight methods and delivery of monoliths:
The government is really making strides to improve technical acquisition, and acquisition in general. The original healthcare.gov semms to have been a wake-up call that will permanently stick and improve government service delivery. I would actually like to do a tour at some point, but I don't think they would take me.
Having said that, there is one three-letter monolith that commands the plurality of the Federal budget and shows absolutely no inclinations to change. They have resisted intrusion by USDS and 18F thus far, and I can tell you from direct experience that their information systems and policies are atrocious. Hopefully 18F, USDS, and similar efforts can eventually penetrate the Five-Sided Playpen, but it is going to be a long, hard slog.
"Fixing" government web has nothing to do with young people. I contracted for 5 years for the Department of Defense doing full stack web. Yes, most people I worked with were double my age or more, but many of them are very talented and eager to implement new technology.
The problem is the massive, unbelievable amount of red tape to get things done. Software stacks and browsers have to get approval and re-approvals, a years-long process. Code has to be written in something stable, not something trendy. The programmers spend more time writing documents and attending meetings than coding. There are meetings about meetings and the layers of management are infinitely recursive (managers for the managers).
Start-up culture and tech trends just don't work at the scale of government, for much the same reasons massive corporations move glacially. Just add even more layers of management, congress, civil service employees that cannot be fired, and tax dollars to the mix.
I enjoyed my time working in government web, but "youth" isn't really an answer.
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.
> 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.
Of course, part of the "fun" is that much of the red tape is put there by (theoretically) well-intentioned people who want to prevent waste, inefficiency and corruption.
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.
Mikey was the first SRE at the scene of healthcare.gov and is now running the new US Digital Service. He works with the folks mentioned in this article and lots of others trying to fix how the government writes software.
I think often fix-it-teams are allowed to do things the regulars are not allowed to do. I have seen several projects where pretty much everybody (except maybe the top managers) knew what's wrong but wasn't allowed to make changes.
Then some crack team (Accenture or "young people") comes in, gets permission to make the necessary changes and gets all the credit.
I applaud the accomplishments of these people. But I don't like the narrative because it is misleading. Lets change context with a nice metaphor and reframe the discussion...
"how a team of immigrants helped bring in a strawberry harvest"
The success of this team is based on a relationship between two things:
1) eagerness to prove one self
2) willingness to suffer pain in order to prove one self
Having worked with a number of them, my experience has been that building things from scratch in big bureaucracies (that aren't software companies) is basically impossible. To much group think inevitably destroys the scoping process.
The teams that have impressed me in big bureaucracies tend to operate in the following manner:
-take/buy something off the shelf that meets 60% of the requirements
-use a team of seasoned project managers and engineers who have seen the darkest gloomiest bloodiest field of battle to incrementally patch and beat that software into the inflexible mold of their bureaucracy
This strategy usually works surprisingly well, but it is like comparing steering a slow moving container ship to a speed boat. It's part of the reason that the agile SaaS market is so successful and profitable.
I first went to work with an organization where a planning meeting was discussing a new feature. Because of my startup culture experience I asked a PM after the meeting "this sounds cool should I whip up a prototype tonight". The project manager laughed and said "this feature set is on the roadmap for 2014 (two years out at the time), we wanted your input but you should be focusing on your existing ticket pipeline". When you consider the scope of the organization the things that they were doing with their core platform was pretty incredible.
That being said it drove me personally nuts, and I quit.
When Blekko was serving web traffic if it came from the primary index and was cached (a repeat request) it was served up in under a millisecond. I learned at Google to never under estimate what sort of performance you could get reading the result out of the memory of a nearby computer. 10,000 computers with 96GB each on them can easily keep 640TB of data ready to return very very quickly. Its even faster if you have your own zero copy TCP/IP layer (right from client memory into the network interface card).
For an example of scale, 10,000 nodes with 96GB each costs less than $30M dollars. The government spent billions on the healthcare.gov project.
For the first time in decades the entire country experienced exactly the government they elected and are paying for. And the beauty of it is that it could not be hidden away, spun or silenced.
What's sad is to see an article such as this one pushing the idea that it was fixed...a "Mission Accomplished" message of sorts. The truth of the matter is that dozens of people should have been fired and a number of them should have ended-up in jail.
Nothing has been fixed. Sure, the website is better but the organization is still being run by he same incompetent morons who created the problem in the first place. That's the problem. And, yes, a bunch of young people can help fix it without writing a line of code by using their brains to vote rather than cargo cult and emotion.
25 comments
[ 2.9 ms ] story [ 67.2 ms ] threadedit: stephengillie called it in his "submarine" comment below (see: http://www.paulgraham.com/submarine.html)
I think this is true. Governments and corporate's are starting to see that you don't need to go with GenericAdAgency12 anymore to get shit-hot, well-made websites going. This project was a textbook example of this.
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.
This is true. But having recently talked with a number of people at 18F and the USDS, I think the enormous scale of the high-profile fuckup is serving as a great example to persuade people that things should be done differently.
For example, note that the government is trying to change the purchasing processes that drive heavyweight methods and delivery of monoliths:
https://18f.gsa.gov/2015/01/08/creating-a-federal-marketplac...
Having said that, there is one three-letter monolith that commands the plurality of the Federal budget and shows absolutely no inclinations to change. They have resisted intrusion by USDS and 18F thus far, and I can tell you from direct experience that their information systems and policies are atrocious. Hopefully 18F, USDS, and similar efforts can eventually penetrate the Five-Sided Playpen, but it is going to be a long, hard slog.
The problem is the massive, unbelievable amount of red tape to get things done. Software stacks and browsers have to get approval and re-approvals, a years-long process. Code has to be written in something stable, not something trendy. The programmers spend more time writing documents and attending meetings than coding. There are meetings about meetings and the layers of management are infinitely recursive (managers for the managers).
Start-up culture and tech trends just don't work at the scale of government, for much the same reasons massive corporations move glacially. Just add even more layers of management, congress, civil service employees that cannot be fired, and tax dollars to the mix.
I enjoyed my time working in government web, but "youth" isn't really an answer.
> 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.
Is there a reason you didn't take the USDS job?
Mikey was the first SRE at the scene of healthcare.gov and is now running the new US Digital Service. He works with the folks mentioned in this article and lots of others trying to fix how the government writes software.
Then some crack team (Accenture or "young people") comes in, gets permission to make the necessary changes and gets all the credit.
"how a team of immigrants helped bring in a strawberry harvest"
The success of this team is based on a relationship between two things: 1) eagerness to prove one self 2) willingness to suffer pain in order to prove one self
Having worked with a number of them, my experience has been that building things from scratch in big bureaucracies (that aren't software companies) is basically impossible. To much group think inevitably destroys the scoping process.
The teams that have impressed me in big bureaucracies tend to operate in the following manner: -take/buy something off the shelf that meets 60% of the requirements -use a team of seasoned project managers and engineers who have seen the darkest gloomiest bloodiest field of battle to incrementally patch and beat that software into the inflexible mold of their bureaucracy
This strategy usually works surprisingly well, but it is like comparing steering a slow moving container ship to a speed boat. It's part of the reason that the agile SaaS market is so successful and profitable.
I first went to work with an organization where a planning meeting was discussing a new feature. Because of my startup culture experience I asked a PM after the meeting "this sounds cool should I whip up a prototype tonight". The project manager laughed and said "this feature set is on the roadmap for 2014 (two years out at the time), we wanted your input but you should be focusing on your existing ticket pipeline". When you consider the scope of the organization the things that they were doing with their core platform was pretty incredible.
That being said it drove me personally nuts, and I quit.
Wow, 30 milliseconds. Subtract out the RTT, and you have app request times on the order of 5ms. Outstanding. And impossible.
For an example of scale, 10,000 nodes with 96GB each costs less than $30M dollars. The government spent billions on the healthcare.gov project.
For the first time in decades the entire country experienced exactly the government they elected and are paying for. And the beauty of it is that it could not be hidden away, spun or silenced.
What's sad is to see an article such as this one pushing the idea that it was fixed...a "Mission Accomplished" message of sorts. The truth of the matter is that dozens of people should have been fired and a number of them should have ended-up in jail.
Nothing has been fixed. Sure, the website is better but the organization is still being run by he same incompetent morons who created the problem in the first place. That's the problem. And, yes, a bunch of young people can help fix it without writing a line of code by using their brains to vote rather than cargo cult and emotion.