I think there are a few issues here. The author points out that there are masters programs springing up whose purpose is to generate revenue. One of my professors calls these mercenary-masters. Often times, these programs segregate their masters students from their undergrads and PhD students - giving them special courses meant for that median mercinary-masters student. That makes it easy to weed out the worst offenders and these programs can be seen as less valuable than a undergraduate degree in CS.

But to put a counterpoint on it, undergraduate education in CS can also be highly variable. My university used to require 20 courses, but because so many other schools required so many fewer, they adjusted down. Heck, most schools don't require students to take operating systems (something that stuck at my school). So, even within undergraduates, I'd say there's a decent difference between someone who took 12 courses, avoiding harder ones and someone who has taken a harder program. In some ways, the same thing that is driving these mercinary-masters programs is driving departments to encourage and keep lower-quality undergraduates within the department.

One of the big problems is that there are a lot of people that want to retrain for software engineering jobs. Yes, they could learn on their own (and many do), but some like the classroom and some like the perceived safety of a piece of paper from a university. We could call these programs post-bac, but that's a lot harder for someone to market on their CV/resumé. So, what is someone that wants to retrain supposed to do? There are undergraduates coming out of top schools with 10-course majors in computer science (including required math courses). As long as the courses are taught at the same level, there's no reason that someone should be able to retrain with those same 10 courses and be seen as having gotten the same education.

So, getting back to the issue at hand, I think there's an issue of whether any CS credential carries the same weight. We only demarcate a few options (BS, MS, PhD), but within a BS, there's huge variation that isn't captured by GPA given that so many schools allow students the option of skipping the hard courses and going with electives like "Web Engineering with Rails" and "Mobile Apps for Android". But part of it is that those course titles offer something that is of value to a lot of companies. For both of those jobs, you don't need to know how a TLB works or why a B-tree is better when doing disk IO. It can be helpful, but there are a lot of jobs that don't need high CS skill.

Maybe the issue is that we don't generally have Software Engineering degrees. There's overlap between software engineering and CS, but I think there's a decent difference worthy of demarcation. Technology is seen as a good path today and I think some of the harder pieces of CS get some people discouraged out of the departments. That usually gives departments two options: water down the major or have fewer achieving the major. Maybe a balance could be struck, maybe a software engineering degree would be the way to go. Maybe universities in America need to start offering MPhil degrees (a research masters) to make the distinction.

But, even if that distinction were made, some schools would be offering software engineering under the CS name and students looking for a fancier piece of paper would send their money that way. We don't have anyone like the AMA dictating standards as they do in medicine. But maybe this is better. Maybe this means that we need to actually look into candidates rather than relying on one piece of paper.