From the people who confused you with the most elementary algorithms comes a series of things you really need to know to do your job! Watch, mystified, as the book which you have a test on in eight hours invents symbols to explain the details of single digit addition! You might have been top of your class in high school and showed promise through your core and basic classes, but just you wait! Our authors have learned and mastered techniques to simultaneously insult your intelligence and dumbfound you with a needless amount of abstraction and complexity! All this can be yours for the low-low price of $280 for our 120 page full color, hardcover book!

I’ve always been upset with textbook publishers, ever since my days in Computer Science 1, sophomore year in high school. The authors of that poorly constructed book (the binding literally only lasted about six months before self-destructing) took some kind of sadistic enjoyment in coming up with unintelligible vocabulary, patterns, and practices in which to subject students. In those days our teacher was our savior; no matter how mind-gratingly stupid and dull the book was, Mr. Patterson invariably sorted things out and never hesitated to say the book was moronic. I have to thank him for saving my sanity or, at least, staving off the inevitable future.

This semester, I draw particular complaint with the book in my databases class, inappropriately named “Fundamentals of Database Systems (5e),”  by Ramez Elmasri and Shamkant B. Navathe. I’ve been writing SQL for about four years now, but it wasn’t untill my last job that I think I really learned the full potential of a database system. My old boss was an absolute god in writing SQL and I  made certain that the learning experience more than accounted for the pay. It was under his tutelage that I learned how well-designed database systems were made and how to retrieve amazing data no one thought possible. I wouldn’t consider myself a sage in designing databases, but I think that I’m definitely qualified to pass judgment on most designs, especially the ones that would be considered “fundamental.”

During the early stages of my class, my professor discussed the all-important topic of table keys. (For my non-programmer friends, you use database keys to look up data in a particular table. Since some tables can have millions of rows, you have to choose a key that is unique and is as small as possible for quick lookup.) It’s a well-held practice in modern databases that the database is really the best agent to tell you what the keys are, so in general, what you want to do is tell it what your data is, and, like a coat-check, it gives you a little token (a 32-bit signed integer) to get your data again. Because the database chooses the key, you can be assured that it is both unique and small enough to quickly look things up. This is known as an auto-increment integer primary key column, mainly because the integer that you’re given is 1 (or some increment) more than the key that was given out last. Even though it’s not a traditional mechanism in database research, every major database (MSSQL, Oracle, MySQL, Protegé) has some incarnation of it. Traditionally, the programmer chooses one or more fields that combined are unique. While this is effective, it takes significantly longer for the server to prepare the key to look up the data and the number of fields that must be duplicated on tables so the original data can be found becomes tremendous. My database professor still disagrees with me, but I have faith that he’ll have an epiphiny sometime and understand and regret the error of his ways.

So why is it that these authors, from whom my professor quotes, have got it all wrong? In lieu of real research, I did some investigative Googling to find the qualifications of these men.

Ramez Elmarsi

• B.S., Electrical Engineering, Alexandria University (Egypt, 1972)
• M.S., Ph.D., Computer Science, Stanford University (1980)

Elmarsi has spent the bulk of his life in research while consulting for Honeywell developing a distributed database testbed and associated tools from 1982 to 1987. He now teaches at the University of Texas at Arlington and consults for various law firms.

Source: http://ranger.uta.edu/~elmasri/

Shamkant B. Navathe

• Ph.D., Industrial and Operations Engineering, University of Michigan (1976)
• M.S., Computer and Information Science, Ohio State University (1970)
• B.E., Electrical Communications Engineering, Indian Institute of Science (1968)
• B.Sc., Physics, Mathematics, University of Poona (India, 1965)

Navathe was a Systems Engineer for IBM from 1968-1969 before working for Electronic Data Systems in 1971. Starting in 1975, Navathe began teaching at NYU as an associate professor and then moved to the University of Florida for a few years until he ultimately settled at the Georgia Institute of Technology, where he teaches now.

Source: http://www.cc.gatech.edu/computing/Database/faculty/sham/

There’s no doubt that these men have the academic prowess demanded by their degrees and both have an extensive list of published works. But what really disturbs me is their professional résumé. Navathe stopped working professionally in 1971 and Elmarsi has never worked as a full-time employee at any company. This is when I understood exactly why my book is heavy on unintuitive mathematical symbols wielded like a bat with barbed wire and light on intelligence or edifying information. This field changes dramatically every couple years and unless you can keep up to date on the very latest technology, you are willing yourself into obsolescence. But yet some charlatans authors have the audacity to publish texts advising the unsuspecting student to continue using the old technologies of yore, rather than using what is new and efficient. Perhaps even more inexcusable is the book selection committee at my university choosing textbooks no one can read, let alone understand to remind all of us undergrad students that we’re not Ph.D.’s and we haven’t joined their elite clique.

I think this problem is far more widespread than I have broached here. A year or so ago, I wrote a letter I never delivered to my dean, more or less as a venting exercise. I think I’m going to clean it up and discuss my points here, in the event someone who can do something stumbles upon my humble blog.

It’s always interesting to see how different people answer the question. Especially people who have or plan to have degrees in it. Dictionary.com defines it as:

the science that deals with the theory and methods of processing information in digital computers, the design of computer hardware and software, and the applications of computers.

I see this broken down into:

• Science
• Theory
• Design of hardware and software
• Applications for computation

Normally, I’d say fighting the dictionary on definitions would be rather fruitless, but this is by far one of the most vague definitions I’ve ever seen. I think a good analog for CS is math and physics. In that much more mature field, mathematics provides laws that say x should exist. It is then up to the applied physicist to prove in a lab that the theory is true. Even then, it is up to a company and its engineers to productize and actually use the fruits of science. Computer Science, in stark contrast according to this definition, is all of those things rolled up into one. It’s no wonder why no one in this field knows what it means.

To me, the entire term “Computer Science” is a huge misnomer. It’s certainly not science. Science, at least to me, involves creating a hypothesis, setting up an experiment, and proving the truth of your assumptions. Last time I checked, there was no such thing in CS. Nobody sits around and hypothesizes about algorithms, let alone commercial programs. I think upper management would have a conniption if their products were experiments.

So what about computers? Surely you use computers in CS! I suppose most of my professors didn’t get that memo, and, historically, that really hasn’t been the case either. Edsger Dijkstra, one of the most renowned computer scientists in our short history, never used a computer. Even his musings, as late as 2001, were handwritten. Dijkstra had a very particular view of CS. To him, Computer Science was purely theory – really quite close to a real science in terms of algorithm design and such. It was his opinion that all these programs we run on our computers are perversions of computation. In the spirit of our forerunner, my professor in Advanced Data Structures forwent computers in favor of the more conventional pencil and paper. To be fair, I’m almost certain he was a machine, based upon his ability to do the most tedious and mundane calculations ad nauseum with the patience of any of Intel’s creations.

Since it seems my degree is almost as ambiguous as a Liberal Arts degree, I will posit my suggestions for changing it. Fortunately, unlike my comparison, my degree is both useful and salvageable.

My university has done a good job of trying to distill the ideas that I’ve covered here, and, for that, I commend them. It is, however, nothing short of unprovidential that they’ve managed to distill one form of mud into two forms of mud. The school offers degrees in Computer Science and Software Engineering. Despite what you might think, SE is hardly its namesake. What they ended up with is a theory-application mix (CS) and a application-business mix (SE). At least it’s a step in the right direction.

I think we need three degrees, as you have probably noticed that I’ve been hinting all along:

1. Theoretical Computation
2. Software Engineering
3. Software Management

Theoretical Computation would focus on algorithm design and computability, as its name suggests. It’s not a science, and it has no computers in it – just computability, or the ability for something to be derived from calculations and deterministic processes.

Software Engineering would actually live up to its name. Programming would be king, like the pencil is to the artist. Software architecture would be a major emphasis, as well as applied algorithm design, which could reach over into Theoretical Computation.

Finally comes Software Management. Because software planning is a huge issue for any company that writes software, be it boxed or internally distributed, we need people who are trained to help the process along. These people need to be business savvy to communicate deadlines and goals to the non-technical arm(s) of the company. Furthermore, Software Management majors have to be technical enough to be able to choose good employees.

A lot of people in the field feel that there will be a strong resistance to change for such a degree plan, even if it makes sense. I can understand the impetus, but at the same time the degree itself hasn’t existed for forty years, so there is always hope for reorganization.