Saturday, May 8, 2010

Save the commentary, please

I am working on a thesis right now on optimizing data structures and algorithms in database systems. I am doing my implementation for the first part in MySql, and will be augmenting one of the storage engines (maybe InnoDB, maybe something else) to test out some of the ideas in my paper.

Anyways, I picked up Understanding MySql Internals to use as a reference for some of the major components of the software. The technical information is pretty good, and its nice to get a discourse on such a large code base.

However, something bothers me about the book. Riddled throughout the technical details are little dollops of over-embellished praise for Monty Wideneous, the creator of MySql. Now, don't get me wrong-- I go a bit ga-ga for rockstar developers like Monty, Rod Johnson, Crazy Bob Lee, etc., but not in a technical book. It's just awkward to be reading about architectual decisions for the threading model in MySql and then read this:

As far as the programming skills were concerned, they were not lacking at all. Just as a good rider becomes one with the horse, Monty had become one with the computer. It pained him to see system resources wasted. He felt confident enough to be able to write virtually bug-free code.
(p. 109)

Hyperbole such as "Monty had become one with the computer" can be excluded from technical books in my opinion.

Here's another example of the Monty "love-fest":

...perhaps building on his God-given talent, Monty developed a habit and ability to write very efficient code naturally. He also developed, or perhaps was gifted from the start, with an unusually acute vision of what needed to be done to the code to make it useful in future development--without knowing in advance much detail about what that future development would be
(p. 1)

He could've removed this entire paragraph and we would know nothing less, except that the author clearly wants to be on Monty's Christmas card list. So, technical book authors: save the commentary, please. ...or maybe just keep it out of the main text and include an optional, opinion-based companion workbook!

For example, accompanying the section on Threads vs Forked Processes, there could be a multiple choice question:

Why did Monty Widenious choose a thread model instead of a forked process model for MySql?
  1. Large amount of shared data between workers
  2. Greater overhead in context switching processes over threads
  3. Greater overhead in creating a forked process over creating a thread
  4. Monty is a man-god, who is incapable of writing bugs in source code


Steve