America’s Tech Guru Steps Down, But He’s Not Done Rebooting the Government(wired.com)
wired.com
America’s Tech Guru Steps Down, But He’s Not Done Rebooting the Government
http://www.wired.com/2014/08/healthcare-gov/
9 comments
Would you say this is different than a theoretical physicist [1] participating in research on a space vehicles mechanical failure [2]? Maybe Mr. Park is just excellent and what was needed, regardless of his degree.
[1] http://en.wikipedia.org/wiki/Richard_Feynman
[2] http://en.wikipedia.org/wiki/Rogers_Commission_Report
[1] http://en.wikipedia.org/wiki/Richard_Feynman
[2] http://en.wikipedia.org/wiki/Rogers_Commission_Report
I don't doubt Mr. Park's talent. It sounds like he was an excellent choice for the position.
I can believe this while also noting that Obama, who has vocally encouraged more young people to get STEM degrees, didn't choose someone with a stem degree to hold the highest technical office in his administration.
I can believe this while also noting that Obama, who has vocally encouraged more young people to get STEM degrees, didn't choose someone with a stem degree to hold the highest technical office in his administration.
The difference is that law and medicine are both highly proceduralized, regulated, and standardized careers, and they both require far more training, at a far deeper level.
Ultimately, though, what matters is experience and skills. Again, in law and medicine, the only way into the profession to gain the experience is to have the degree. That's not the case in the tech world.
Ultimately, though, what matters is experience and skills. Again, in law and medicine, the only way into the profession to gain the experience is to have the degree. That's not the case in the tech world.
Right - but then why are STEM degrees so important? Then why is Obama encouraging young people to pursue them? Even he didn't choose someone with a STEM degree to hold the highest technical office in his administration.
I also have a different perspective from you on STEM degrees. It's true that tech has a "lower barrier to entry" if all you look at is official, legal, licensed barriers.
But majoring in STEM fields is vastly more difficult than a major typical of a law school graduate, and elite STEM graduate programs have vastly higher attrition rates than elite law or medical schools (like, 50-100 times higher). The coursework is exceptionally rigorous and difficult.
The difference is that you don't strictly have to do this to go into high tech - lots of people don't. And that's great. But then, again - why is Obama pushing STEM?
I also have a different perspective from you on STEM degrees. It's true that tech has a "lower barrier to entry" if all you look at is official, legal, licensed barriers.
But majoring in STEM fields is vastly more difficult than a major typical of a law school graduate, and elite STEM graduate programs have vastly higher attrition rates than elite law or medical schools (like, 50-100 times higher). The coursework is exceptionally rigorous and difficult.
The difference is that you don't strictly have to do this to go into high tech - lots of people don't. And that's great. But then, again - why is Obama pushing STEM?
Actually it's possible to enter the legal profession without a law degree, apprentice under a practicing lawyer and then take the bar and become a lawyer. It's the path President Lincoln took. While it's not as common now as it was in his day, it's still a well-trodden path in many states.
http://www.nytimes.com/2014/08/03/education/edlife/how-to-le...
http://www.nytimes.com/2014/08/03/education/edlife/how-to-le...
More legally regulated is the only real difference.
I don't envy this guy; what he's dealing with is a very hard problem.
Government tech has the unfortunate problem of requiring instant scale. As in whenever you develop a new app or tool, it needs to roll out to a hundred thousand (or hundred million in the case of healthcare.gov) people and needs to integrate with dozens or even hundreds of different systems. Which of course, is the entire problem to begin with.
It's pretty obvious that the old way of doing things is not sustainable. Most people would say the answer is Agile processes; but that has drawbacks in a government context. Agile can mean many things. Depending on how you implement it, but there is an inescapable trade-off of efficiency for oversight. Government contracts need oversight; otherwise you have contractors who aren't meeting their obligations and collecting millions of dollars while throwing obviously unqualified people at a problem. Often nobody on the government side is even paying attention that the work isn't getting done until it's too late.
I really don't know what the answer is here. There are lots of problems with the government procurement process, but there is a lot of money on the line and the people receiving it have a vested interest in maintaining the status quo. Ultimately the procurement process is the biggest issue. Contracts go to the company that can navigate the procurement process most effectively; not the company best suited to do the job. Given the bureaucratic nightmare that is government procurement, any procurement process designed to find the best company for the job will still ultimately reward the companies most adept at gaming the system through back channels (e.g. calling in a favor with a Congressman to ensure the criteria for contractor selection benefit a specific company).
Government tech has the unfortunate problem of requiring instant scale. As in whenever you develop a new app or tool, it needs to roll out to a hundred thousand (or hundred million in the case of healthcare.gov) people and needs to integrate with dozens or even hundreds of different systems. Which of course, is the entire problem to begin with.
It's pretty obvious that the old way of doing things is not sustainable. Most people would say the answer is Agile processes; but that has drawbacks in a government context. Agile can mean many things. Depending on how you implement it, but there is an inescapable trade-off of efficiency for oversight. Government contracts need oversight; otherwise you have contractors who aren't meeting their obligations and collecting millions of dollars while throwing obviously unqualified people at a problem. Often nobody on the government side is even paying attention that the work isn't getting done until it's too late.
I really don't know what the answer is here. There are lots of problems with the government procurement process, but there is a lot of money on the line and the people receiving it have a vested interest in maintaining the status quo. Ultimately the procurement process is the biggest issue. Contracts go to the company that can navigate the procurement process most effectively; not the company best suited to do the job. Given the bureaucratic nightmare that is government procurement, any procurement process designed to find the best company for the job will still ultimately reward the companies most adept at gaming the system through back channels (e.g. calling in a favor with a Congressman to ensure the criteria for contractor selection benefit a specific company).
Agree, and having worked for the government (as a contractor) for over 20 years before leaving, I'll point out another issue. They want budget and schedule. Somebody has to pay for a system, and they can't go to the hill and ask for "some" money. Agile acknowledges that you don't know everything up front, but with that is the concomitant fact that you cannot give a budget and schedule. So, should the government hire me or you to do a job? Is it even worth paying for? And yes, am I executing on what I promised?
The results in messed up. We always strove, after winning, to write a rational requirements document that acknowledge the uncertainty. Most times they 'got it' and accepted that sort of management style, but there were also times when you'd be tasked to do something utterly useless because of some "shall" in a requirements document that is now hopelessly out of date. But it depends. A half million $ contract you can have that conversation. $60million+, several subcontractors? Not so much.
The results in messed up. We always strove, after winning, to write a rational requirements document that acknowledge the uncertainty. Most times they 'got it' and accepted that sort of management style, but there were also times when you'd be tasked to do something utterly useless because of some "shall" in a requirements document that is now hopelessly out of date. But it depends. A half million $ contract you can have that conversation. $60million+, several subcontractors? Not so much.
[deleted]
I would say that Agile processes is definitely a part of solution (and I have been part of Agile teams and implemented Agile processes within the government), especially because of the oversight it can allow.
It can allow more oversight; but that oversight comes at the expense of efficiency. It can be manageable if the organization is relatively flat, but that's almost never the case in government.
What eventually happens is that to give oversight to the decision makers on a sufficiently large project, your dev leads spend all day in status update meetings with scrum masters, who spend all day in status update meetings with project managers, who spend all day in status update meetings with directors and functional leads. Decisions are made a level above that, so you've got 5 levels of management in a big game of telephone.
It's still probably better than the alternative, but Agile doesn't give you the certainty around schedule and budget that waterfall does. There's a mindset in the government that often manages around schedule and budget ONLY; so it will take rooting out several generations of government project managers to really start to crack the problem.
Like I said, I don't envy the guy. But his bar for success is so low that it would be hard not to improve things.
What eventually happens is that to give oversight to the decision makers on a sufficiently large project, your dev leads spend all day in status update meetings with scrum masters, who spend all day in status update meetings with project managers, who spend all day in status update meetings with directors and functional leads. Decisions are made a level above that, so you've got 5 levels of management in a big game of telephone.
It's still probably better than the alternative, but Agile doesn't give you the certainty around schedule and budget that waterfall does. There's a mindset in the government that often manages around schedule and budget ONLY; so it will take rooting out several generations of government project managers to really start to crack the problem.
Like I said, I don't envy the guy. But his bar for success is so low that it would be hard not to improve things.
"Agile" is very popular for upcoming next gen tech projects in the intelligence community partly because budgets are so erratic and progress is much more scrutinized than before (sequester may be over technically but you wouldn't think so if you look for job listings in the DC area). The problem is that even that process is not unaffected by the waterfall and spiral externalities of who these projects must ultimately answer to and (much more importantly) receive headcount and budget from to accomplish a goal. I'm familiar with one project where iterations / sprints took about 2 months each. Comparing this to the precedent of top 50 enterprise size orgs taking half a year to deploy one... or one thousand physical servers due to sheer bureaucracy in the name of checks and balances... well we should not be trying to compare ourselves to the worst to just make ourselves feel better. It's not like low morale is the primary reason for low performance in enterprise work for so long.
I think exclusive contracts should be abandoned anywhere they can be. Why should there only be one monolithic Healthcare.gov? Every single company that wants to should be able to build their own solution to this. They can be rewarded based on how many users they get, or the best one can win a bounty.
I agree that exclusive contracts should be abandoned where they can be, but for a much different reason: I have little or no confidence at all in the private sector to meet the requirements properly. A lot of the work done by private contractors ought to be done and maintained directly the government. The current system is not one of efficiency; it's one of corporate welfare.
>'I think exclusive contracts should be abandoned anywhere they can be. Why should there only be one monolithic Healthcare.gov?'
I completely agree with the first sentence conceptually, but think the second is a terrible fit for that concept.
A monolithic healthcare.gov actually makes a lot of sense as every implementation will necessarily have loads of shared functionality.
There's a reason state exchanges have spent multiples of what healthcare.gov has per sign-up. [1]
>'Every single company that wants to should be able to build their own solution to this. They can be rewarded based on how many users they get, or the best one can win a bounty.'
This isn't a throwaway chat app. The tacit Government approval of free-for-all collection of the SSNs, income and health coverage information that go into a marketplace application would not be wise.
1: http://www.npr.org/blogs/health/2014/05/08/310721495/healthc...
I completely agree with the first sentence conceptually, but think the second is a terrible fit for that concept.
A monolithic healthcare.gov actually makes a lot of sense as every implementation will necessarily have loads of shared functionality.
There's a reason state exchanges have spent multiples of what healthcare.gov has per sign-up. [1]
>'Every single company that wants to should be able to build their own solution to this. They can be rewarded based on how many users they get, or the best one can win a bounty.'
This isn't a throwaway chat app. The tacit Government approval of free-for-all collection of the SSNs, income and health coverage information that go into a marketplace application would not be wise.
1: http://www.npr.org/blogs/health/2014/05/08/310721495/healthc...
There were suppose to be 50 healthcare.govs. Unfortunately, the intransigence of some Republican governors have left us with more states than intended falling back on a Federal solution.
One of the governing principles of the ACA was that the states would be afforded the ability to experiment with their own approaches to meet the law's guidelines, the other states could replicate what worked. Would have been a wonderful opportunity to try 50 differnent ways to bid, design and build the same system...
One of the governing principles of the ACA was that the states would be afforded the ability to experiment with their own approaches to meet the law's guidelines, the other states could replicate what worked. Would have been a wonderful opportunity to try 50 differnent ways to bid, design and build the same system...
I do not think what you are suggesting is a bad idea. But a counterargument would be that having many organizations doing the same thing might make it more expensive overall, by increasing the cost of overheads (e.g., every company needs to have its own HR department). Those costs may not manifest themselves outright, but they will go into the cost equation.
I really really wish that governments would define some specs for what a patient record MUST and MUST NOT do; and what the software must and must not do, and so on, and then just let software providers sell software to medical providers.
[deleted]
>>The VA is a prime example of antiquated government computing; its main systems run on a 1960s vintage system called MUMPS, a dead digital language that few people under retirement age know how to use.
This is simply untrue. This language is now called 'M', and has been standardized as recently as 2005. All of TD Ameritrade's trades are processed on an M database.
M was doing NoSQL, web-scale computing on commodity hardware before many of us were even born. It can integrate with NodeJS (http://www.kitware.com/blog/home/post/465).
Look into Rob Tweed's ongoing work with M (http://gradvs1.mgateway.com/download/mumps-acceptable.pdf) http://www.mgateway.com/docs/universalNoSQL.pdf http://robtweed.wordpress.com/
This is simply untrue. This language is now called 'M', and has been standardized as recently as 2005. All of TD Ameritrade's trades are processed on an M database.
M was doing NoSQL, web-scale computing on commodity hardware before many of us were even born. It can integrate with NodeJS (http://www.kitware.com/blog/home/post/465).
Look into Rob Tweed's ongoing work with M (http://gradvs1.mgateway.com/download/mumps-acceptable.pdf) http://www.mgateway.com/docs/universalNoSQL.pdf http://robtweed.wordpress.com/
Just because it's still being maintained does NOT mean it's not antiquated and does NOT mean it's a good use of taxpayer money.
Just because its old tech doesn't mean its bad either - when one very large employer I used to work with turned off its old in house payroll system written in COBOL the second month of the new brought in system was a disaster 70% or so of the staff didn't get paid :-)
I cant say more as I was sworn to secrecy but lets say some very stupid contract operators had a large part to play
I cant say more as I was sworn to secrecy but lets say some very stupid contract operators had a large part to play
Sure, but COBOL is also a huge maintenance cost compared to something written in, say, java, which has no end of somewhat versed developers.
That rather depends on how competent those "no end of developers" are. From my experience of Perl+Ruby developers, I'd be amazed if even 1% of Java developers were good enough to migrate an existing system without catastrophic results. And those 1% are a) hard to find, b) very expensive and c) likely already tied up and hoarded like gold-egg laying geese.
Yes if your one of the worlds largest users of IBM mainframes as this company is finding good Cobol programmers is not going to be hard.
You don't think it is possible that in the 30 years since the original system was written, things have become a little inane?
??inane?? WTF are you smoking mate
PARIS the in house system was updated for 20+ years quite successfully never missing a run.
And you do know that for serious HPC a lot of work Is still done in the venerable Fortran (look at job adverts for CERN) and yes people use Python for some of that now as well but the Libraries that do the heavy lifting are Fortran ones.
PARIS the in house system was updated for 20+ years quite successfully never missing a run.
And you do know that for serious HPC a lot of work Is still done in the venerable Fortran (look at job adverts for CERN) and yes people use Python for some of that now as well but the Libraries that do the heavy lifting are Fortran ones.
I used MUMPS at my last job, I'd say antiquated is the perfect word for it.
Procurement is an exceedingly hard problem to conquer and its acute for software. I personally think that government should move to a two tiered architecture. Creating API's allows them to make projects small enough that more nimble and agile firms can participate.
Philadelphia tried this exact thing and built its procurement atop Github:
http://civic.io/2013/03/27/experiments-in-github-based-procu...
Philadelphia tried this exact thing and built its procurement atop Github:
http://civic.io/2013/03/27/experiments-in-github-based-procu...
I don't understand - "More broadly, the government’s entire approach to technology was top-down and inflexible", so the solution is to hire more people at the top (White House)? It seems to me that "government IT" is such a vast concept, ranging from the physical computers at each DMV to healthcare.gov, to Medicare billing systems (not to mention the NSA)... Wouldn't it make more sense for individual agencies to re-jigger their IT policies, rather than some broad and vague White House initiative?
> Wouldn't it make more sense for individual agencies to re-jigger their IT policies
How do you get bureaucracies to do that though?
Not by fiat from the top. The system simply doesn't work that way, the career bureaucrats have usually made a career out of subverting the orders that come from politicians which they don't like. Read Robert Gates's book about him running the DoD to see what he had to do to get some progress on some things at DoD, and then realize that most agencies are not lead by people as capable as Gates.
That's why they are hiring some people near the top. The USDS will serve as the White House's eyes and ears for agency management of IT, and the bureaucrats within the agencies can either get on board (and get performance evals listing how they helped supported "Presidential efforts") or try to get in the way (and get caught by staff at the USDS who can actually call them out on their bullshit and teach agency heads how to spot bullshit).
Cachet isn't everything in DC, but it is a lot of what you need for change to occur.
How do you get bureaucracies to do that though?
Not by fiat from the top. The system simply doesn't work that way, the career bureaucrats have usually made a career out of subverting the orders that come from politicians which they don't like. Read Robert Gates's book about him running the DoD to see what he had to do to get some progress on some things at DoD, and then realize that most agencies are not lead by people as capable as Gates.
That's why they are hiring some people near the top. The USDS will serve as the White House's eyes and ears for agency management of IT, and the bureaucrats within the agencies can either get on board (and get performance evals listing how they helped supported "Presidential efforts") or try to get in the way (and get caught by staff at the USDS who can actually call them out on their bullshit and teach agency heads how to spot bullshit).
Cachet isn't everything in DC, but it is a lot of what you need for change to occur.
But that depends on the government’s success in luring great people to revive the dead zone of government IT.
In my experience, that's only a part of the problem - good people usually don't stick around for too long (since they don't want to deal with the inertia and other difficulties of this environment).
Also, I take issue that only "great people" can be found in Silicon Valley - for example, I recently developed a web application for the government (as a contractor) that's modern, mobile-ready and which uses MongoDB.
In my experience, that's only a part of the problem - good people usually don't stick around for too long (since they don't want to deal with the inertia and other difficulties of this environment).
Also, I take issue that only "great people" can be found in Silicon Valley - for example, I recently developed a web application for the government (as a contractor) that's modern, mobile-ready and which uses MongoDB.
>'In my experience, that's only a part of the problem - good people usually don't stick around for too long (since they don't want to deal with the inertia and other difficulties of this environment).'
In my experience, the worst danger of sticking around in Government is the appearance of being 'part of the problem' when it comes time to move on.
In my experience, the worst danger of sticking around in Government is the appearance of being 'part of the problem' when it comes time to move on.
> "Vets applying for benefits face a laborious process using an outdated interface written in Delphi"
Great article, but why the Delphi hate? I use Delphi 7 daily at my current job, and I actually quite like it.
Great article, but why the Delphi hate? I use Delphi 7 daily at my current job, and I actually quite like it.
How much must you like Delphi for you to see hatred where there is none?
The interface is outdated, the language is just another fact. Would you assume someone is hating on C in a sentence such as "This is an outdated program written in C."?
The assumption you make leads me to believe that you don't like Delphi as much as you claim, and yourself recognize that the language itself is outdated as well.
Which, as a daily Delphi 7 user, is something I'm sure you have come to realize a long time ago. :)
The interface is outdated, the language is just another fact. Would you assume someone is hating on C in a sentence such as "This is an outdated program written in C."?
The assumption you make leads me to believe that you don't like Delphi as much as you claim, and yourself recognize that the language itself is outdated as well.
Which, as a daily Delphi 7 user, is something I'm sure you have come to realize a long time ago. :)
[deleted]
> Achievements that Internet companies seem to pull off effortlessly are tougher than Mars probes for federal agencies.
Survivorship bias.
Survivorship bias.
It's generally a good thing that you can follow more than one path to tech, and I honestly don't think what you major in is all that critical. But I'm going to have to admit, with a bit of embarrassment, that it's a little depressing to hear that an econ major is the highest tech guy in government, and that a president who emphasizes the importance of science and engineering didn't choose someone with that background to lead.