Eric Schmidt is working to launch a university

This will fail not because it's a bad idea, but because the government will reject it.

Contrary to popular belief, established universities do a very effective job of preparing tech talent for government jobs. The issues, which Schmidt seems to miss, are twofold:

(1) the government, with few exceptions, is a TERRIBLE place to build effective tech skills. Slow, heavily outsourced, bureaucratic beyond belief, and low paid, there is very little creativity and variety in which to build unique technology, and no reward for the BS.

(2) Current universities already prepare tech workers well. In some cases, there are even joint CS-Public Policy degrees (e.g., MSCAPP at UofC).

Those engineers with policy expertise just don't want to work for the government. I know; I was one of them, and I could not for the life of me find a policy tech job that paid even HALF what tech companies would pay me.

Schmidt should focus on building "the department of innovative technology" and pay engineers appropriately.

>I'm sure ES also has a vision for a modern university that has merit,

I don't disagree with any of your points. Cornell Tech in NYC is arguably an example of reimagining things with at least a somewhat clean sheet of paper but I haven't studied it in any detail. One thing that is probably be clear is that there's too much stovepiping in universities in general. MIT's new interdisciplinary Stephen A. Schwarzman College of Computing is another example of trying to bring more disciplines under one roof.

Well there's utility and then there's legacy.

You could argue that we could use better schools or schools that have more of a focus on subjects needed by a modern workforce. But there's no real shortage of colleges and universities. Yes, existing universities come with lots of legacy entanglements (which can be good as well as bad) but for the most part you're probably better off investing in those schools than tearing down and starting from scratch on a prairie somewhere.

Interesting. I don't see the point, though.

The issue with the US government and software is not a lack of talent (within the country, or even within the government itself). But a poor structuring and assigning of responsibilities and a severely risk-averse culture, paired with the overreaction of a risk-accepting culture occasionally showing up and fucking it all.

There is, or will be, sufficient talent in the US to maintain and develop government software systems. Flat out, people keep going into CS and software engineering degree programs. Programming itself is ludicrously accessible compared to nearly any other technical discipline because the cost of entry is about $200 and time.

The problems that actually need to be resolved:

1. Government employees (contrary to popular opinion) are grossly underpaid for their expertise. This leads many of the best to leave and go to private industry and/or government contractors. Those who remain are truly civic minded, or zombies. Moving away from GS helps here (pay for time in grade), but the alternatives are also severely abused. NSPS paid people for changing positions, so there was a ton of job hopping before it was canceled. Expertise wasn't really cultivated, only the same stupid culture of bouncing between jobs you find in parts of private industry. AcqDemo is somewhat better, but in implementation lost all its potential value. Still better than GS, but only barely.

2. In-house development shops are typically made to compete for contracts in the same way as private companies. This creates some interesting conflicts within the organizations. And a ton of the in-house software development efforts are spent on maintenance, not developing new systems. So a different kind of expertise shows up, but not the expertise needed when truly novel projects start up.

3. The people in charge of the IT and software development efforts are usually inexperienced with IT and software development. They're either straight out of college EEs (CS people are at a disadvantage in many government shops) or career civil servant bureaucrats. The latter rely on those same inexperienced EEs. This leads to an incredibly advantage for contractors to push program offices around because they can come off as reliable experts, until you've been burned a few times. But hit a couple milestones and the civil servant in charge is already promoted out of that position and a new one is left holding the bag when shit hits the fan.

4. Risk averse IT severely restricts development environments even when software is made in-house. This leads to incredible slowdowns and often automation is impossible due to having to develop and test on multiple test/dev network enclaves that are separated even from each other. An example is the typical CCB (configuration control board) process which is a monthly (at best) meeting where, mostly, managers decide what new things can be installed on the network. You want an updated version of VS or GCC? Gotta wait a month. You want to use a common library? Gotta wait a month. And that's on top of the delays imposed by security scans (a manual process, that could be automated if it's necessary).

5. Risk accepting IT goes too far the other way as a reactionary response to the risk averse culture that held them back. Their fuck ups lead to the people in (4) being able to justify their positions and cement their culture.

You have to improve the approach to IT, the staffing of the acquisition offices to have competent individuals in the appropriate fields, not just successful (from a promotion perspective) bureaucrats, and probably increase pay across the board for technical people.