Uneducational Crisis Pt. 2: Subject Matter

When I think about these last four years, I don't usually think about the university. Much more important and interesting things have been happening in my life. I think that says something about the quality of education as a life experience: you only consider it important when you're forced to do it during the better part of your day.

But when I do think about the university, the first thing that comes to mind are the professors. I've had a few excellent professors who were a pleasure to study with, but the rest ranged from merely disinterested to downright inept. In my previous post, I covered this topic in detail.

The second thing that comes to mind is what I learned. Or rather, what I was supposed to learn. Now that the things are drawing to their unceremonious end, it's amazing to look back and see just how many things I've been told were

• misleading
• wrong
• obsolete
• stupid
• some or all of the above

With a lot of real-life experience in software industry, you can afford to be told such things because your brain will reject them automatically after a brief examination. But the reason I started writing about the educational problems in CS is not because I feel cheated out of my money, but because of the kids who go to the university to try to learn.

You see, I love programming and I like doing it for a living. And I enjoy the company of other people who do it. Sure, school might not matter if you're good enough (and infatuated enough). The knowledge is out there and you can learn it all by yourself. But you might not find it soon enough and you might get the wrong ideas at school and you might come out of it all utterly confused or frustrated or suffer some other damage. There's enough stuff in real life that will confuse and frustrate you, no need to start out like that.

So what's wrong with the stuff they teach you at the university?

Obsolescence

I agree that learning about the past is important. You need some context if you want to understand not only the how, but also the why of the things you see today. But that's no excuse for teaching obsolete stuff.

Take waterfall model, for example. For a big enough project, as most of real-world projects are, it simply does not work -- there are too many things that can go wrong and will go wrong. And yet the universities insist on teaching it as the way to execute software development projects.

Another good example is the insistence on Design Flow Diagrams. I'm not implying that DFDs are obsolete. Nor am I saying the same about any other concept from SSADM. Had any of our professors bothered to teach us SSADM well, I might have learned enough to compare it to what I'm used to working with.

As far as DFDs go, I find them stunningly imprecise and uncomfortable, compared to UML. This, of course, is a topic for a discussion that goes beyond the scope of this post, but it's also a bit beside the point. The point is that if the course is called Systems Analysis and Design, I don't think it can stay locked in time forever, covering SSADM in depth and merely mentioning the existence of UML and iterative processes and the myriad of other techniques that evolved in the mean time.

Scope

The problem with SSADM vs. UML is just an specific case of a bigger and more general problem: the scope is all wrong. If you are going to give an OOP course, you should take care to explain what OOP is, what OOP isn't, why it's been invented, how it works, etc. Sounds reasonable, but it doesn't happen. What you get instead is a Java course, where in the first few classes you get a very brief, confused and inaccurate summary of OOP concepts and then you delve into the language specifics.

I love learning new languages. As Kevin Kelleher notes, each language tries to solve some problem. That means that each new language you learn might teach you about a new class of problems or a new class of solutions. The thing is, you have to realize what the problems are and why they are problems before you can benefit from learning a new language. Otherwise you're just learning syntax.

You could do it the way I did it: learn a new language, compare it with the one you knew before and gradually become aware of the new problems. After enough time and enough new languages, you'll be able to think of languages in terms of problems and solutions. Indeed, nothing can completely replace the process of learning from your own experience. But that doesn't mean you aren't entitled to decent formal education.

It's like your parents telling you not to play with fire. You might heed their advice and still get burned by something you didn't know was hot. Or you might disregard their advice and get burned. But if they didn't tell you not to play with fire you would surely get burned out of ignorance.

Specialization

The problem of scope is what you'll see on the individual course level. But when you take a step back and examine the entire course curriculum, you'll find yourself facing the opposite extreme: breadth. The sheer breadth of subjects covered combined with the scope of each course makes you wonder why you got yourself into this at all.

Here's a bit of news for the guys who design the educational program: most of the software developers don't need to know about the implementation specifics of the datalink layer in ISDN. Nor do most network experts really need to know how to design a database in the third normal form.

I understand why the universities do this. It's a lot more manageable to have your courses flow sequentially and give everyone who survives the same diploma. Teach them all and let job sort them out. The question is, should ease of management excuse the poor results? Let's put it to a test: what would you think of a manager who told you, before the project started, that you'll have to implement a web-based user interface, a Swing GUI and an interactive textual interface, because it's easier to plan the project that way than to plan for capturing the UI requirements?

Relevance

All of the problems I've described here could be easily summarised in one word: relevance. Obsolete subjects are irrelevant to what you'll be doing. Courses with wrong scope teach you irrelevant things. Lack of specialization ensures you'll be learning a lot of irrelevant stuff. I postulate that every problem with the subject matter in CS education can be filed under relevance.

So how do we solve this? I hate doing this, but I'm afraid I have to do a Robert Jordan and leave you hanging. By now I've built enough context to engage in a discussion that I wanted to start from the beginning, but that discussion merits its own post. Therefore, I have no choice but to say RAFO.

At least I promise to finish in the third post.

Uneducational Crisis Pt. 1: Human Factor

If there's one thing worse than a bad programmer, it's a failed programmer turned professor. I don't know how common this is in United States, but here in Chile you see it a lot. And try as I might to pretend that I don't care, it's actually driving me nuts. Quite understandably, too: I could be doing interesting things instead of trying to guess what the latest in a row of brain-dead dilettantes wants me to write as a solution to his "ingenious" exam exercise.

On the other hand, this way I get the first-hand insight into the problems with education in CS field. Some of these problems, I suppose, are local and owe their existence to a variety of economic, political and technological factors, but I'm convinced that some are universal. Nonetheless, I shall not discriminate: I'll go over them all and a plague on both their houses.

This article, the first in the series, deals with the professors themselves.

Two Roads Diverged in a Yellow Wood...

Over the time, I learned to distinguish two types of CS professors:

1. The Geek. This guy knows his stuff, because he actually works in computer industry and does his job well. Sometimes he is motivated by a genuine desire to teach new generations, but often he is teaching just to make a bit of money on the side or to lend a bit of academic weight to his name. More often than not, he is wonderfully inept at imparting his knowledge to the students, because he's a computer geek, not a teacher. All in all, he's guaranteed to be relaxed, easy-going and flexible. Mostly harmless.
   
2. The Prima Donna. Who needs knowledge when you have Orwellian authority? This is the guy who will typically boast at least 20 years of experience in computer industry, who has a prominent consulting company and is certified by Carnegie Mello [sic] University. His classes are pure poetry. Vogon poetry, to be precise.

The Prima Donna is the type that does the most damage, so he merits detailed dissection.

Spot the Prima Donna

A Prima Donna professor is rather easy to recognize. He will exhibit a combination of several seamlessly coupled behavioral patterns from the following list:

• Smugness. Usually one of the first signs that you're dealing with a Prima Donna is that self-satisfied attitude aimed to make you feel that some day, with lots of effort and a divine intervention or two, you'll get to be as good as this guy.
• Hand Waving. One of the most valuable techniques for explaining the unknown is the hand waving. To those who came to learn, it seems that the Prima Donna is making a herculean effort to explain the concept and that they are simply too dumb to understand him.
• Stating the Obvious. A good presentation slide will show only the key concepts and leave the explanation to the presenter. A bad presentation slide will show all the information in a pile of text you won't bother to read. In both cases, the Prima Donna will repeat the contents of the slide, with lots of Hand Waving, and you'll be left no wiser than before.
  
• Exasperation. Sometimes a braver student will ask the Prima Donna to clarify something previously "explained" by Hand Waving and Stating the Obvious. If the Prima Donna is not in the mood to do it all again, he'll inform the audience that he explained it several times already.
• Selective Hearing. If there's a student willing to press the issue despite the Exasperation, the Prima Donna might choose to answer another student's unrelated query or to simply go on to the next topic.
• Condescension. You never know when you might get lucky: sometimes a Prima Donna will even give away unearned points when correcting an exam. But don't worry, he will make sure to inform you about it.
• Objective Subjectivity. He might be teaching you how to solve problems that have more than one correct solution, but you better make sure you solve the problems the way Prima Donna taught you to do it.
• Asserting the Authority. The Prima Donna will make sure you don't forget that he's the professor and you're the student, which means you owe him certain respect. He'll be especially sensitive about certain forms of disrespect, such as disagreeing with him.
• Showcasing the Merits. In case you don't seem to be convinced of the Prima Donna's authority, you'll be informed of one or more of his certifications, nominations, recognitions, citations, publications, you-get-the-idea-tions.
  

Occasionally, you might get really unlucky and wind up with an embodiment of the archetypal Prima Donna. If there is an option to get the authorities to replace him, go for it.

Damage Done

It's becoming increasingly popular to be a nerd. Sure, you're still going to be bullied in school, but at least now you know you might be in store for a bright future. And those around you know it too. People tend to pay attention to things that might make them rich and when one of the richest persons in the world is downright nerdy, you can bet it won't go unnoticed.

The net result is that you get a lot of CS students who are in it for the glory and riches. These people don't know a lot about computers, but that's okay, because they're there to learn. The problem is that a lot of them also lack the talent. They're simply not good at computer science or any natural science at all.

Imagine all these people trying to learn about pointers from a Geek professor. Confusion abounds, chaos reigns supreme and in the end a lot of them will either fail the course (and hopefully change major) or pass the course having learned nothing.

Now imagine them trying to learn about pointers from a Prima Donna. Apart from becoming utterly frustrated and dejected, they'll learn a lot of garbage. The things that will stick the most are the parts that the Prima Donna invented or misinterpreted, because those are the most vivid explanations the Prima Donna will offer. That's the core of what makes him an "eminence" in the "computing world".

And now imagine yourself working with them on a project. Imagine working on a piece of code that has to traverse a tree with a co-worker who believes that "recursion is for programmers who have no style." Imagine hunting down an interoperability bug caused by bad handling of character encoding in a code written by a person who has been taught that "ASCII table is physically implemented in the microprocessor." Imagine writing business logic that has to use a database designed by someone convinced that a transactional database must satisfy the fifth normal form.

Not a cheerful thought, is it?

Foreword

Once I thought I wouldn't create a blog, ever. Then I started changing my mind, thanks to Joel Spolsky, Steve Yegge and Paul Graham. They had it all: interesting content, charismatic style and challenging opinions. But even so, my opinion of blogging went mostly along the lines that I had nothing substantial to say that these guys didn't already say or couldn't say it better. Which, of course, is quite irrelevant, true though it might be. As soon as that realization filtered through my thick skull, I decided to take the final step and inflict my thoughts on the rest of the world.

The first thing my blog needed was a name. Coming up with one wasn't nearly as hard as I dreaded -- I only went through three iterations:

1. Paradogma Shift. Not bad, but it doesn't really represent what I want to talk about. Besides, I'd like to save the word paradogma for other purposes.
2. Overflow Dump. Closer to the topic. Also, the initials are a nice touch: whenever I "overdose" on things that are stupid, ridiculous or utterly unacceptable, I can go and post to my blog. But, it makes it sound as if my posts are garbage and I'd like the benefit of a doubt.
3. Beard's Eye. A modest word play and an obscure reference to Cryptonomicon -- what more could I wish for?

Here it is, then. My own beard's eye view onto society. I hope it's not too hairy.