I would say this article is discussing two separate problems: (1) the gulf between research and practical software development, and (2) low-quality C.S. graduat

I would say this article is discussing two separate problems: (1) the gulf between research and practical software development, and (2) low-quality C.S. graduates. IMHO, the first is not really a problem, or at least not a big one. Part of the way a field advances is that researchers are free to try out any old idea, to see if it is any good. Most of them aren't, but we don't know which are worthwhile until we try them out. So it helps that researchers are disconnected from the process of making salable products. "Make something that sells in two months" is not a good way to get people to try out interesting new ideas. The result is a slow filtering of ideas from research into practice. Occasionally, a university researcher comes up with something that the programmer on the street can immediately pop into a product (RSA encryption, bump mapping, Introsort, ...) but this is not the norm; nor, I think, should we expect it to be. The second problem (low-quality C.S. graduates) is more serious. The writer's suggestions are not particularly new; they amount to putting more of what is often called "software engineering" into the C.S. curriculum. And part of the problem there is that it is difficult to do large projects in a university course setting. When you don't do large projects, all that stuff (teams, complexity management, ...) is not really needed. So, while this second problem is worth pointing out, I don't think there are going to be any quick fixes for it.