SQLite is always the first project that springs to mind when people ask those, "What's the most beautiful/robust/clean/well-designed/effective piece of code you've worked with?" kinds of questions. I used it way back in its very earliest incarnation to deal with a BerkeleyDB based project that had gotten too relational for its own good, and it was an absolute joy. One of those shining moments of, "This is what software development is supposed to be like." The level of friction in development (and the lines of code) just fell away at a ridiculous rate, and I finished the long overdue project within a few hours of the switch to SQLite. (This was an extreme case, and borne of my own ignorance of the problem domain and having never used relational databases and not recognizing when my problem was a relational one, but it sticks in my memory, nonetheless, and SQLite gets most of the credit.)
Well, the internals of SQLite are far from beautiful or clean. I do agree that the external interface is very nice to use, and the docs are actually useful.
Are you a C coder? I can't imagine any experienced C coder would say that of SQLite. It's a beautiful codebase. Among the best I've ever seen, if not the best.
Yes, I am a C coder. The variable names use awful Hungarian notation, but are often otherwise tersely named beyond that. It could use more whitespace to signify logical blocks instead of running all the logic in a function together. It's well commented except for the confusing parts, like the concurrency logic and the memory management, which seems rather backwards.
By contrast, both the Linux kernel and WebKit are far more beautiful codebases than SQLite, and also deal with far more complexity. If SQLite's the best you've seen, you haven't really seen much...
So, I have to admit that it's been a long time since I've read the code (version 2.x). I don't find Hungarian notation offensive, as long as naming conventions are consistently applied. If they aren't consistently applied in SQLite, then I guess that'd be a problem worth complaining about. I also don't find terseness and compact functions offensive. Whitespace is good, but not mandatory, as long as there is consistency...humans are adaptable, and once accustomed to a particular whitespace convention (whatever it is), it's usually fine. More lines fit on a page, anyway, and that has some value.
So, even if naming conventions are inconsistent and there's not enough whitespace, it is still a nice piece of code. The interfaces are very nice and clean (which does apply to internally used interfaces, as well, as I recall it), which is extremely important. It is also among the best tested pieces of C code in the world, with ridiculously high test coverage, which is good, too...it also means it is better documented than a lot of code, since the tests tend to provide a second tier of code documentation (you can see how the interface, both internal and world-facing, is used and what it's supposed to return).
I won't argue that Linux or WebKit aren't nicer. I've spent more time in the Linux kernel sources than any other major C project (except maybe Squid), and it is definitely a really great codebase. I don't know WebKit, at all, so won't comment. Linux has dramatically less test coverage than SQLite, and is also tersely commented and documented. I kinda suspect your opinion of the SQLite bits that are poorly commented comes from the contrast with the places where it is commented in vivid and verbose detail (I seem to recall there was/is some form of literate programming going on in SQLite, but maybe that was another project).
SQLite is used by OS X Mail, Firefox, and plenty of other widely deployed apps. With that many users, even the most obscure branches get exercised. Finding the bugs through internal testing is a better life than reading end user trouble tickets all day.
This is awesome stuff, but the fact still remains that for a lot of software, it just doesn't matter if it crashes occasionally. I'm not saying you shouldn't test. I'm saying that not all projects (and probably not even most) require the same degree of reliability and testing that SQLite requires.
I don't get some of the analogies in the presentation. Like, how can I run a music production with an iPod? I'm also not so sure the sides of the brain comparison really captures what they want to say.
