America’s Tech Guru Steps Down, But He’s Not Done Rebooting the Government
wired.com
wired.com
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.
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.
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.
http://www.nytimes.com/2014/08/03/education/edlife/how-to-le...
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?
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).
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...
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...
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.
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.
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/
I cant say more as I was sworn to secrecy but lets say some very stupid contract operators had a large part to play
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.
Philadelphia tried this exact thing and built its procurement atop Github:
http://civic.io/2013/03/27/experiments-in-github-based-procu...
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.
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, the worst danger of sticking around in Government is the appearance of being 'part of the problem' when it comes time to move on.
Great article, but why the Delphi hate? I use Delphi 7 daily at my current job, and I actually quite like it.
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. :)
Survivorship bias.